[OpenAFS] Transfer rates under OpenAFS client for Windows

[Danko Antolovic]

Brian,
thanks, I have seen the same/similar descriptions. The crux of it seems 
to be that rxMaxMTU (packet size) must be no larger than 
FastSendDatagramThreshold, else the UDP packet is sent to the "slow" 
route by Windows. Keeping rxMaxMTU at 1024, or increasing 
FastSendDatagramThreshold above its default of 1024, has more or less 
the same effect on network utilization.

If you gain any detailed insight into the "slow" vs. "fast" mechanism, 
I'd like to hear about it. CPU load is indeed a bit higher in the fast 
mode, as you pointed out.

Policywise, leaving parameters undefined comes down to trusting either 
the OpenAFS community or Microsoft to do the right things in the future. 
Granted, MS charges for its services, but my expectations regarding 
these two bodies are otherwise fairly similar.

Regards,
Danko



On 07/06/2012 03:37 PM, Dyer, Rodney wrote:
>
> 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
>
>