[OpenAFS] Transfer rates under OpenAFS client for Windows
Danko Antolovic
dantolov@indiana.edu
Thu, 5 Jul 2012 17:26:28 -0400
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\TransarcAFSDaemon\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 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: 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
:??