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-ad...@openafs.org [mailto:openafs-info-ad...@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

:��T���&j)b�   b�өzpJ)ߢ�^��좸!��l��b��(���~�+����Y���b�ا~�����~ȧ~

Reply via email to