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

Katsushi Kobayashi ikob at koganei.wide.ad.jp
Wed Sep 27 05:23:21 PDT 2006

I presented a sample NIC implementation for fine
grained packet pacing:


In my experience fine grained pacing is easy and small
foot-print size compared with complete TCP offload.

Also, I believe NIC vendor is already aware packet pacing
effect as:

I2 will not approve the result using a special hardware.
So, I believe Chelsio implemented packet pacing feature in
released product.

Katsushi Kobayashi

On 2006/09/27, at 18:53, Marko Zec wrote:

> 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

More information about the end2end-interest mailing list