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: [email protected] [mailto:[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 :?? _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
