We recently saw disappointing AFS performance on fast Linux machines on gigabit Ethernet compared to e.g. NFS, despite tricks like bypassing the AFS cache etc. so I undertook to measure a simple RX application which just creates a single call and issues a jumbo rx_Write on it, i.e. memory-to-memory.

The result was disappointing: best I could get was around 45 MB/s transfer rate on two 1 GHz dual CPU machines. As a comparison, a very simple minded UDP 'flooder' saturates at around 97 MB/s between those machines. The CPU load during the RX test is slightly over 50% well distributed over both CPU's (why on both?). Repeating the test on two 2GHz XEON machines did not show any improvement. Conclusion: the protocol introduces waits.

Are the default values in RX for window size, ack rate etc. still adequate for today's networks? I tried to play around a bit: increased # of pcks/jumbogram, receive/transmit window size etc. (every time bluntly changing rx_globals.h and rebuilding libafsrpc.a). Nothing really happened. The only improvement we got was cranking up the MTU to around 9K (on a 10GB card that supported it).

Any ideas?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke        http://cern.ch/~rtb         [EMAIL PROTECTED]  O__
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

Reply via email to