[OpenAFS-devel] Bad AFS performance over wide area due to packet fragmentation problems

[Rainer Toebbicke]

Harald Barth schrieb:
>> As '-nojumbo' has a measurable price on our own local network where
>> fragmentation does not exhibit any problem we hesitate to run
>> everything in that mode.
> 
> I run with -nojumbo and with RX_MAX_FRAG patched to 1.
> 
> On which clients/servers do you see that this would have a performance
> penalty? 
> 
> Last time I checked on Linux there was no difference in letting the RX
> code produce 4 UDP packets a ~1400 bytes which then are as many
> eternet frames compared to let RX produce 1 packet a ~5600 bytes and
> then the OS fragment it into 4 ethernet packets. Yes, there was a
> difference back in the days of SunOS 4.1.4....
> 
> Harald.
> 

Harald,

I used an RX memory-two-memory transfer program with exact timing. 
Yes, there is a measurable difference of the order of 10-20%.

This was early this year, under 1.4.4 or 1.4.6, on reasonably powered 
Linuces. Admittedly in laboratory conditions, machines on same switch, 
identical configurations that give a good speed match and hence small 
queue sizes. Transfer rates in excess of 110 MB/s. Realistic 
conditions usually produce a much wider spread.

Not that I'm in favour of jumbograms - just that they still do a good 
job. The RX implementation certainly deserves some more attention with 
respect to queue handling, window adjustments and the like, the gain 
may then turn out smaller.

For wide-area the gain is probably negligible, hence turning them off 
is likely to get rid of a problem for free. I haven't yet come around 
trying that RX patch Derrick mentioned.



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155