[OpenAFS] Transfer rates under OpenAFS client for Windows
Dyer, Rodney
rmdyer@uncc.edu
Fri, 6 Jul 2012 19:37:23 +0000
--_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Danko,
Probably making the change to "FastSendDatagramThreshold" is what you want =
to do. I've reading quite a bit about this setting, and getting conflictin=
g reasoning on whether the default should be changed. For example, on this=
page...
http://technet.microsoft.com/fr-fr/library/cc781532%28v=3Dws.10%29.asp=
x
... we see...
FastSendDatagramThreshold
Value Type: REG_DWORD
Default: 1024
Description: Datagrams smaller than the value of this parameter go through =
the fast I/O path or are buffered on send. Larger ones are held until the d=
atagram is actually sent. The default value was found by testing to be the =
best overall value for performance. Fast I/O means copying data and bypassi=
ng the I/O subsystem, instead of mapping memory and going through the I/O s=
ubsystem. This is advantageous for small amounts of data. Changing this val=
ue is not generally recommended.
However this page...
http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_=
web.aspx
... says...
"Windows Server 2003 uses the FastSendDatagramThreshold registry key to det=
ermine whether a datagram should go through the fast I/O path or should be =
buffered during a send operation. Fast I/O means that the server bypasses t=
he I/O subsystem and copies data directly to the network interface buffer.
The default value of the FastSendDatagramThreshold key is 1024. If the numb=
er of packets in a stream exceeds this value, additional operations are nec=
essary. As a result, CPU utilization and context switches increase, while t=
he maximum number of simultaneous clients that the server can handle decrea=
ses. Performance tests showed that changing the default threshold setting t=
o a higher value, such as 1500 bytes, improves server performance.
In general, only high-bit-rate streams are affected by changing this key. P=
acket sizes larger than 1024 bytes usually appear in content that has bit r=
ates higher than 100 Kbps. A side effect of changing this key value is an i=
ncrease in the number of non-paged pool bytes allocated for the server. Thi=
s change does not cause any significant problems."
I can't find any information on whether the default value of 1024 from Micr=
osoft has changed under Windows 7 or Server 2008.
It is generally not a good idea to change the OpenAFS client service "rxMax=
MTU" value from 0 (zero) unless you have good reason to do so. In another =
email to me, Jeffery Altman states "... the problem with setting RxMaxMTU (=
to a specific value besides zero*) is that it disables every future thing w=
e (the AFS developers*) will do to improve Rx throughput". *My emphasis.
So I think the best path is to leave "rxMaxMTU" at 0 (zero), and set "FastS=
endDatagramThreshold" to 1500. That shouldn't cause any of your other appl=
ications problems. The setting seems to control only how much "stress" you=
r CPU is under.
Rodney
Rodney Dyer
Operations and Systems (Specialist)
Mosaic Computing Group
William States Lee College of Engineering
University of North Carolina at Charlotte
> -----Original Message-----
> From: Danko Antolovic [mailto:dantolov@indiana.edu]
> Sent: Thursday, July 05, 2012 5:26 PM
> To: Dyer, Rodney; openafs-info@openafs.org
> Subject: RE: [OpenAFS] Transfer rates under OpenAFS client for Windows
>
> The parameter RxMaxMTU makes a difference: when it is set to 1024, using =
Intel
> 82567LM NIC, network utilization is close to 100% for both reads and writ=
es with
> Windows AFS client. Thanks for the germane information, Rodney.
>
>
> My system configuration: Dell Latitude, 2.53 GHz, 32-bit, 3.45 GByte RAM,
> 100 mbit/s Ethernet port, Intel 82567LM Gigabit NIC.
>
> Windows XP, paging file size is 5302 MBytes, although that is probably no=
t
> critical.
>
> Open AFS client version 1.7.1500.
>
> This set of AFS client configuration parameters works reasonably well on =
my
> system:
>
> Key Name:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TransarcAFSDaem
> on\Param
> eters
> Class Name: <NO CLASS>
> Last Write Time: 7/5/2012 - 4:17 PM
> Value 0
> Name: HideDotFiles
> Type: REG_DWORD
> Data: 0x1
>
> Value 1
> Name: <NO NAME>
> Type: REG_SZ
> Data:
>
> Value 2
> Name: IsGateway
> Type: REG_DWORD
> Data: 0x0
>
> Value 3
> Name: RxMaxMTU
> Type: REG_DWORD
> Data: 0x400
>
> Value 4
> Name: NetbiosName
> Type: REG_SZ
> Data: AFS
>
> Value 5
> Name: Cell
> Type: REG_SZ
> Data: iu.edu
>
> Value 6
> Name: MountRoot
> Type: REG_SZ
> Data: /afs
>
> Value 7
> Name: NoFindLanaByName
> Type: REG_DWORD
> Data: 0x1
>
> Value 8
> Name: FreelanceClient
> Type: REG_DWORD
> Data: 0x1
>
> Value 9
> Name: UseDNS
> Type: REG_DWORD
> Data: 0x1
>
> Value 10
> Name: SecurityLevel
> Type: REG_DWORD
> Data: 0x1
>
> Value 11
> Name: SMBAuthType
> Type: REG_DWORD
> Data: 0x2
>
> Value 12
> Name: CacheSize
> Type: REG_DWORD
> Data: 0xc3500
>
> Value 13
> Name: ChunkSize
> Type: REG_DWORD
> Data: 0x15
>
> Value 14
> Name: ServerThreads
> Type: REG_DWORD
> Data: 0x28
>
> Value 15
> Name: Daemons
> Type: REG_DWORD
> Data: 0x10
>
> Value 16
> Name: Stats
> Type: REG_DWORD
> Data: 0x4e20
>
>
>
>
>
> -----Original Message-----
> From: openafs-info-admin@openafs.org [mailto:openafs-info-
> admin@openafs.org]
> On Behalf Of Dyer, Rodney
> Sent: Tuesday, July 03, 2012 9:40 PM
> To: jaltman@your-file-system.com; openafs-info@openafs.org
> Subject: RE: [OpenAFS] Transfer rates under OpenAFS client for Windows
>
> I'm not sure if this information still applies here, but back in 2010 I d=
id some testing
> and found that some of our DELL client machines with Intel based "on boar=
d"
> network chips performed significantly slower on writes than reads. We we=
re using
> Windows XP Pro SP3 (32bit). The OpenAFS client was the 1.5 series at the=
time.
>
> After more research I found that changing the rxMaxMTU to a value of 512 =
to
> 1024 on our network increased the write speed up to 150 percent.
>
> If I set the value rxMaxMTU from 1024 to 1025, the performance of the cli=
ent
> dropped by at least half.
>
> The poor performance only seems to appear on two models of Dell clients..=
.
>
> Dell OptiPlex 760, with "Intel(R) 82567LM-3 Gigabit Network Connection"
> Dell OptiPlex 755, with "Intel(R) 82566DM-2 Gigabit Network Connection"
>
> All other Dell machines that I've tested with the "Broadcom NetXtreme 57x=
x Gigabit
> Controller" were ok with either 0 (zero), or 1260 set as "rxMaxMTU".
>
> This was tested in multiple offices on multiple machines.
>
> Normally the AFS client automatically determines the MaxMTU if the rxMaxM=
TU is
> set to 0.
>
> The issue was not really with the OpenAFS client, it was with how the Int=
el network
> driver was interacting with Windows.
>
> There was more research done and found that changing the Windows
> "FastSendDatagramThreshold" to something like 1500 solved the problem.
> However I was never sure if I wanted to change the Microsoft "default" on=
all our
> machines.
>
> We never implemented a mass roll-out network configuration change to our
> Windows client machines to fix the problem. I just quietly let the probl=
em drop on
> the floor. So the problem still exists in our environment.
>
> Rodney Dyer
>
>
> > -----Original Message-----
> > From: openafs-info-admin@openafs.org
> [mailto:openafs-info-admin@openafs.org] On
> > Behalf Of Jeffrey Altman
> > Sent: Tuesday, July 03, 2012 8:31 PM
> > To: openafs-info@openafs.org
> > Subject: Re: [OpenAFS] Transfer rates under OpenAFS client for Windows
> >
> > On 7/3/2012 4:27 PM, Danko Antolovic wrote:
> >
> > > My first question is why copying from the client to the file server
> > > is so much slower (by a factor of 2 or 3) than the other way
> > > around. The other question is why the network utilization, at least
> > > as reported under Windows, never approaches the line rate, even at
> > > quiet times, but rather stays below the caps of 70 and 30 percent.
> >
> > It won't go any faster with the OpenAFS RX implementation.
> >
> > Jeffrey Altman
>
> :??
--_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Arial","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Arial","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Danko,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Probably making the change to "FastSendDatag=
ramThreshold" is what you want to do. I've reading quite a bit a=
bout this setting, and getting conflicting reasoning on whether the default=
should be changed. For example, on this page...<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText"> <a href=3D"http://techne=
t.microsoft.com/fr-fr/library/cc781532%28v=3Dws.10%29.aspx">
http://technet.microsoft.com/fr-fr/library/cc781532%28v=3Dws.10%29.aspx</a>=
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">... we see...<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><b>FastSendDatagramThr=
eshold<o:p></o:p></b></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i><o:p> </o:p></=
i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><b>Value Type</b>: REG=
_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i><o:p> </o:p></=
i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><b>Default</b>: 1024<o=
:p></o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i><o:p> </o:p></=
i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><b>Description</b>: Da=
tagrams smaller than the value of this parameter go through the fast I/O pa=
th or are buffered on send. Larger ones are held until the datagram is actu=
ally sent. The default value was found
by testing to be the best overall value for performance. Fast I/O means co=
pying data and bypassing the I/O subsystem, instead of mapping memory and g=
oing through the I/O subsystem. This is advantageous for small amounts of d=
ata.
<b>Changing this value is not generally recommended</b>.<i><o:p></o:p></i><=
/p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">However this page...<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText"> <a href=3D"http://www.mi=
crosoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx">
http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.a=
spx</a><o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">... says...<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i>"Windows Serve=
r 2003 uses the FastSendDatagramThreshold registry key to determine whether=
a datagram should go through the fast I/O path or should be buffered durin=
g a send operation. Fast I/O means that the
server bypasses the I/O subsystem and copies data directly to the network =
interface buffer.<o:p></o:p></i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i><o:p> </o:p></=
i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i>The default value o=
f the FastSendDatagramThreshold key is 1024. If the number of packets in a =
stream exceeds this value, additional operations are necessary. As a result=
, CPU utilization and context switches
increase, while the maximum number of simultaneous clients that the server=
can handle decreases. Performance tests showed that changing the default t=
hreshold setting to a higher value, such as 1500 bytes, improves server per=
formance.
<o:p></o:p></i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><i><o:p> </o:p></=
i></p>
<p class=3D"MsoPlainText" style=3D"margin-left:.5in"><b><i>In general, only=
high-bit-rate streams are affected by changing this key. Packet sizes larg=
er than 1024 bytes usually appear in content that has bit rates higher than=
100 Kbps. A side effect of changing
this key value is an increase in the number of non-paged pool bytes alloca=
ted for the server. This change does not cause any significant problems</i>=
</b><i>."<o:p></o:p></i></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">I can't find any information on whether the defau=
lt value of 1024 from Microsoft has changed under Windows 7 or Server 2008.=
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">It is generally not a good idea to change the Ope=
nAFS client service "rxMaxMTU" value from 0 (zero) unless you hav=
e good reason to do so. In another email to me, Jeffery Altman states=
"<i>... the problem with setting RxMaxMTU (</i><span style=3D"font-si=
ze:9.0pt">to
a specific value besides zero</span><i>*) is that it disables every future=
thing we (</i><span style=3D"font-size:9.0pt">the AFS developers</span><i>=
*) will do to improve Rx throughput</i>". *My emphasis.<o:p></o:=
p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">So I think the best path is to leave “rxMax=
MTU” at 0 (zero), and set “FastSendDatagramThreshold” to =
1500. That shouldn’t cause any of your other applications probl=
ems. The setting seems to control only how much “stress” =
your CPU is
under.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Rodney<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Rodney Dyer<o:p></o:p></p>
<p class=3D"MsoNormal">Operations and Systems (Specialist)<o:p></o:p></p>
<p class=3D"MsoNormal">Mosaic Computing Group<o:p></o:p></p>
<p class=3D"MsoNormal">William States Lee College of Engineering<o:p></o:p>=
</p>
<p class=3D"MsoNormal">University of North Carolina at Charlotte<o:p></o:p>=
</p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">> -----Original Message-----<o:p></o:p></p>
<p class=3D"MsoPlainText">> From: Danko Antolovic [mailto:dantolov@india=
na.edu]<o:p></o:p></p>
<p class=3D"MsoPlainText">> Sent: Thursday, July 05, 2012 5:26 PM<o:p></=
o:p></p>
<p class=3D"MsoPlainText">> To: Dyer, Rodney; openafs-info@openafs.org<o=
:p></o:p></p>
<p class=3D"MsoPlainText">> Subject: RE: [OpenAFS] Transfer rates under =
OpenAFS client for Windows<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> The parameter RxMaxMTU makes a difference: w=
hen it is set to 1024, using Intel<o:p></o:p></p>
<p class=3D"MsoPlainText">> 82567LM NIC, network utilization is close to=
100% for both reads and writes with<o:p></o:p></p>
<p class=3D"MsoPlainText">> Windows AFS client. Thanks for the germane i=
nformation, Rodney.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> My system configuration: Dell Latitude, 2.53=
GHz, 32-bit, 3.45 GByte RAM,<o:p></o:p></p>
<p class=3D"MsoPlainText">> 100 mbit/s Ethernet port, Intel 82567LM Giga=
bit NIC.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Windows XP, paging file size is 5302 MBytes,=
although that is probably not<o:p></o:p></p>
<p class=3D"MsoPlainText">> critical.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Open AFS client version 1.7.1500.<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> This set of AFS client configuration paramet=
ers works reasonably well on my<o:p></o:p></p>
<p class=3D"MsoPlainText">> system:<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Key Name:<o:p></o:p></p>
<p class=3D"MsoPlainText">> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\=
Services\TransarcAFSDaem<o:p></o:p></p>
<p class=3D"MsoPlainText">> on\Param<o:p></o:p></p>
<p class=3D"MsoPlainText">> eters<o:p></o:p></p>
<p class=3D"MsoPlainText">> Class Name: &nb=
sp; <NO CLASS><o:p></o:p></p>
<p class=3D"MsoPlainText">> Last Write Time: 7/5/2012 - 4:17=
PM<o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 0<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; HideDotFiles<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x1<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 1<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; <NO NAME><o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_SZ<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data:<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 2<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; IsGateway<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x0<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 3<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; RxMaxMTU<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x400<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 4<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; NetbiosName<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_SZ<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; AFS<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 5<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; Cell<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_SZ<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; iu.edu<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 6<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; MountRoot<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_SZ<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; /afs<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 7<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; NoFindLanaByName<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x1<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 8<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; FreelanceClient<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x1<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 9<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; UseDNS<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x1<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 10<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; SecurityLevel<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x1<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 11<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; SMBAuthType<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x2<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 12<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; CacheSize<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0xc3500<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 13<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; ChunkSize<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x15<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 14<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; ServerThreads<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x28<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 15<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; Daemons<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x10<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Value 16<o:p></o:p></p>
<p class=3D"MsoPlainText">> Name: &nb=
sp; Stats<o:p></o:p></p>
<p class=3D"MsoPlainText">> Type: &nb=
sp; REG_DWORD<o:p></o:p></p>
<p class=3D"MsoPlainText">> Data: &nb=
sp; 0x4e20<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> -----Original Message-----<o:p></o:p></p>
<p class=3D"MsoPlainText">> From: openafs-info-admin@openafs.org [mailto=
:openafs-info-<o:p></o:p></p>
<p class=3D"MsoPlainText">> admin@openafs.org]<o:p></o:p></p>
<p class=3D"MsoPlainText">> On Behalf Of Dyer, Rodney<o:p></o:p></p>
<p class=3D"MsoPlainText">> Sent: Tuesday, July 03, 2012 9:40 PM<o:p></o=
:p></p>
<p class=3D"MsoPlainText">> To: jaltman@your-file-system.com; openafs-in=
fo@openafs.org<o:p></o:p></p>
<p class=3D"MsoPlainText">> Subject: RE: [OpenAFS] Transfer rates under =
OpenAFS client for Windows<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> I'm not sure if this information still appli=
es here, but back in 2010 I did some testing<o:p></o:p></p>
<p class=3D"MsoPlainText">> and found that some of our DELL client machi=
nes with Intel based "on board"<o:p></o:p></p>
<p class=3D"MsoPlainText">> network chips performed significantly slower=
on writes than reads. We were using<o:p></o:p></p>
<p class=3D"MsoPlainText">> Windows XP Pro SP3 (32bit). The OpenAF=
S client was the 1.5 series at the time.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> After more research I found that changing th=
e rxMaxMTU to a value of 512 to<o:p></o:p></p>
<p class=3D"MsoPlainText">> 1024 on our network increased the write spee=
d up to 150 percent.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> If I set the value rxMaxMTU from 1024 to 102=
5, the performance of the client<o:p></o:p></p>
<p class=3D"MsoPlainText">> dropped by at least half.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> The poor performance only seems to appear on=
two models of Dell clients...<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Dell OptiPlex 760, with "Intel(R) 82567=
LM-3 Gigabit Network Connection"<o:p></o:p></p>
<p class=3D"MsoPlainText">> Dell OptiPlex 755, with "Intel(R) 82566=
DM-2 Gigabit Network Connection"<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> All other Dell machines that I've tested wit=
h the "Broadcom NetXtreme 57xx Gigabit<o:p></o:p></p>
<p class=3D"MsoPlainText">> Controller" were ok with either 0 (zero=
), or 1260 set as "rxMaxMTU".<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> This was tested in multiple offices on multi=
ple machines.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Normally the AFS client automatically determ=
ines the MaxMTU if the rxMaxMTU is<o:p></o:p></p>
<p class=3D"MsoPlainText">> set to 0.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> The issue was not really with the OpenAFS cl=
ient, it was with how the Intel network<o:p></o:p></p>
<p class=3D"MsoPlainText">> driver was interacting with Windows.<o:p></o=
:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> There was more research done and found that =
changing the Windows<o:p></o:p></p>
<p class=3D"MsoPlainText">> "FastSendDatagramThreshold" to som=
ething like 1500 solved the problem.<o:p></o:p></p>
<p class=3D"MsoPlainText">> However I was never sure if I wanted to chan=
ge the Microsoft "default" on all our<o:p></o:p></p>
<p class=3D"MsoPlainText">> machines.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> We never implemented a mass roll-out network=
configuration change to our<o:p></o:p></p>
<p class=3D"MsoPlainText">> Windows client machines to fix the problem.&=
nbsp; I just quietly let the problem drop on<o:p></o:p></p>
<p class=3D"MsoPlainText">> the floor. So the problem still exists=
in our environment.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Rodney Dyer<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> > -----Original Message-----<o:p></o:p></=
p>
<p class=3D"MsoPlainText">> > From: openafs-info-admin@openafs.org<o:=
p></o:p></p>
<p class=3D"MsoPlainText">> [mailto:openafs-info-admin@openafs.org] On<o=
:p></o:p></p>
<p class=3D"MsoPlainText">> > Behalf Of Jeffrey Altman<o:p></o:p></p>
<p class=3D"MsoPlainText">> > Sent: Tuesday, July 03, 2012 8:31 PM<o:=
p></o:p></p>
<p class=3D"MsoPlainText">> > To: openafs-info@openafs.org<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">> > Subject: Re: [OpenAFS] Transfer rates u=
nder OpenAFS client for Windows<o:p></o:p></p>
<p class=3D"MsoPlainText">> ><o:p></o:p></p>
<p class=3D"MsoPlainText">> > On 7/3/2012 4:27 PM, Danko Antolovic wr=
ote:<o:p></o:p></p>
<p class=3D"MsoPlainText">> ><o:p></o:p></p>
<p class=3D"MsoPlainText">> > > My first question is why copying f=
rom the client to the file server<o:p></o:p></p>
<p class=3D"MsoPlainText">> > > is so much slower (by a factor of&=
nbsp; 2 or 3) than the other way<o:p></o:p></p>
<p class=3D"MsoPlainText">> > > around. The other question is why =
the network utilization, at least<o:p></o:p></p>
<p class=3D"MsoPlainText">> > > as reported under Windows, never a=
pproaches the line rate, even at<o:p></o:p></p>
<p class=3D"MsoPlainText">> > > quiet times, but rather stays belo=
w the caps of 70 and 30 percent.<o:p></o:p></p>
<p class=3D"MsoPlainText">> ><o:p></o:p></p>
<p class=3D"MsoPlainText">> > It won't go any faster with the OpenAFS=
RX implementation.<o:p></o:p></p>
<p class=3D"MsoPlainText">> ><o:p></o:p></p>
<p class=3D"MsoPlainText">> > Jeffrey Altman<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> :??<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
</div>
</body>
</html>
--_000_18B8F39B03C7B445B4C3B97D55D4555B0B3DE9RPITSEXMS2itsuncc_--