Danko,
Probably making the change to "FastSendDatagramThreshold" is what you want to
do. I've reading quite a bit about this setting, and getting conflicting
reasoning on whether the default should be changed. For example, on this
page...
http://technet.microsoft.com/fr-fr/library/cc781532%28v=ws.10%29.aspx
... 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 datagram
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 bypassing the I/O
subsystem, instead of mapping memory and going through the I/O subsystem. This
is advantageous for small amounts of data. Changing this value 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
determine 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 the
I/O subsystem and copies data directly to the network interface buffer.
The default value of 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 threshold setting to a
higher value, such as 1500 bytes, improves server performance.
In general, only high-bit-rate streams are affected by changing this key.
Packet sizes larger 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 allocated for the server. This
change does not cause any significant problems."
I can't find any information on whether the default value of 1024 from
Microsoft has changed under Windows 7 or Server 2008.
It is generally not a good idea to change the OpenAFS client service "rxMaxMTU"
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 we (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
"FastSendDatagramThreshold" to 1500. That shouldn't cause any of your other
applications problems. The setting seems to control only how much "stress"
your 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:[email protected]]
> Sent: Thursday, July 05, 2012 5:26 PM
> To: Dyer, Rodney; [email protected]
> 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 writes
> 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 not
> 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: [email protected] [mailto:openafs-info-
> [email protected]]
> On Behalf Of Dyer, Rodney
> Sent: Tuesday, July 03, 2012 9:40 PM
> To: [email protected]; [email protected]
> 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 did
> some testing
> and found that some of our DELL client machines with Intel based "on board"
> network chips performed significantly slower on writes than reads. We were
> 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 client
> 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 57xx
> 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 rxMaxMTU is
> set to 0.
>
> The issue was not really with the OpenAFS client, it was with how the Intel
> 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 problem
> drop on
> the floor. So the problem still exists in our environment.
>
> Rodney Dyer
>
>
> > -----Original Message-----
> > From: [email protected]
> [mailto:[email protected]] On
> > Behalf Of Jeffrey Altman
> > Sent: Tuesday, July 03, 2012 8:31 PM
> > To: [email protected]
> > 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
>
> :??
