[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
zec at tel.fer.hr
Thu Sep 28 09:39:20 PDT 2006
On Thursday 28 September 2006 02:02, Rick Jones wrote:
> >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.
> We industry types have to because the researchers keep adding straws to
> TCP's back and increasing the path length :) And because the IEEE types
> won't standardize a larger MTU each time they increase the bit-rate by an
> order of magnitude...
> >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...
> If they trigger losses, then the cwnd's kick-in and the TSO's become
It's obvious that doing hardware TSO for say an 8 K data chunk, i.e. 5
segments, provides great savings in terms of CPU cycles and I/O bus
utilization spent on transmitting TCP streams. But what is the performance
gain for going up from 8 K / 5 segment TSO to 64 K / 44 segment bursts,
knowing that bursts that large clearly coudl be a double-edged sword?
In other words, how large the TSO bursts could be considered tolerable and
justified - roughly where should we draw the line?
More information about the end2end-interest