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