On Sun, 30 Mar 2008 13:03:18 +0800 Adrian Chadd <adrian@creative.net.au> wrote:
Oh, and kernel hz tickers can have similar effects on network traffic, if the application does dumb stuff. If you're (un)lucky then you may see 1 or 2ms of delay between packet input and scheduling processing. This doesn't matter so much over 250ms + latent links but matters on 0.1ms - 1ms latent links.
(Can someone please apply some science to this and publish best practices please?)
There's been a lot of work done on TCP throughput. Roughly speaking, and holding everything else constant, throughput is linear in the round trip time. That is, if you double the RTT -- even from .1 ms to .2 ms -- you halve the throughput on (large) file transfers. See http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html for one summary; feed "tcp throughput equation" into your favorite search engine for a lot more references. Another good reference is RFC 3448, which relates throughput to packet size (also a linear factor, but if serialization delay is significant then increasing the packet size will increase the RTT), packet loss rate, the TCP retransmission timeout (which can be approximated as 4x the RTT), and the number of packets acknowledged by a single TCP acknowledgement. On top of that, there are lots of application issues, as a number of people have pointed out. --Steve Bellovin, http://www.cs.columbia.edu/~smb