[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
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
I2 will not approve the result using a special hardware.
So, I believe Chelsio implemented packet pacing feature in
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
>> 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
>> 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
>> it's not actually hard, you just need to RTFM.
> The question whether or not we can implement fine-grained pacing in
> might be becoming less relevant now that the silicon industry is
> pushing with TCP segmentation offload implementations in hardware.
> 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
> wire-speed burst at minimum. Thinking what things might look like if
> multiple such streams would get synchronized is quite scarry...
More information about the end2end-interest