[OpenAFS] Transfer rates under OpenAFS client for Windows
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
Open AFS client version 1.7.1500.
This set of AFS client configuration parameters works reasonably well on my
Class Name: <NO CLASS>
Last Write Time: 7/5/2012 - 4:17 PM
Name: <NO NAME>
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Dyer, Rodney
Sent: Tuesday, July 03, 2012 9:40 PM
To: email@example.com; firstname.lastname@example.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.
> -----Original Message-----
> From: email@example.com
> Behalf Of Jeffrey Altman
> Sent: Tuesday, July 03, 2012 8:31 PM
> To: firstname.lastname@example.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