latency (was: RE: cooling door)

Sun Mar 30 17:08:38 UTC 2008

On Sun, 30 Mar 2008 13:03:18 +0800
Adrian Chadd <adrian at 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