[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?

[Marko Zec]

On Tuesday 26 September 2006 20:39, David P. Reed wrote:
> Fred Baker wrote:
> > As Bob says, systems often have fairly obnoxious timing signals
> > available to them. One might hope that this could get fixed :-(
>
> Not that it should matter, but I write network code every day for XP,
> OSX and Linux.  Perhaps the grandees who manage are still living in past
> decades.
>
> The days when end-system clocks had really lousy resolution are gone,
> gone, gone.   While getting resolution below a millisecond is still not
> always possible, all of these platforms, when running on 500 MHz
> processors or better, do just fine with minimal overhead when running
> activities that need to be scheduled with millisecondish granularities.
>
> Of course it's a little harder to do this in user space, one needs to
> know how to manage user space thread priorities.  But in the kernel,
> where networking is usually done, it's no problem.   And in user space
> it's not actually hard, you just need to RTFM.

The question whether or not we can implement fine-grained pacing in software 
might be becoming less relevant now that the silicon industry is irreversibly 
pushing with TCP segmentation offload implementations in hardware.  Given 
that the OS typically feeds a TSO engine with at least a 32 or 64 kbyte raw 
data chunk per single TCP session, this corresponds to a 22 or 44 segment 
wire-speed burst at minimum.  Thinking what things might look like if 
multiple such streams would get synchronized is quite scarry...

Marko