Re: latency (was: RE: cooling door)

On Sun, 30 Mar 2008 13:03:18 +0800
Adrian Chadd <adriancreative.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/thr
u-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.columbi
a.edu/~smb

 

> ... feed "tcp throughput equation" into your
favorite search
> engine for a lot more references. 

There has been a lot of work in some OS stacks
(Vista and recent linux kernels) to enable TCP
auto-tuning (of one form or another), which is
attempting to hide some of the worst of the TCP
uglynesses from the application/end-users.  I
am not convinced this is always a good thing,
since having the cruft exposed to the developers
(in particular) means one needs to plan for
errors and less than ideal cases.

Gary