On Wed, Oct 14, 2009 at 06:45:32AM -0500, Jeff Bacon wrote:
> > There's a fundamental clash between desktop switch design and TCP operation
> > on
> > recent operating systems. Switches like 3560G by default buffer 100
> > MTU-sized
> > packets, i.e. something like 150 kB of data. 3560Es are even worse, they
> > only
> > buffer 64 MTU-sized packets by default (~100 kB of data).
> >
> > But in recent Linux kernels (as well as in Windows Vista) TCP buffer
> > autotuning
> > rises TCP window to megabyte(!) ranges. Hence a *single* TCP connection has
> > no
> > problem to overrun the buffer space and cause large amount of drops.
>
> <random>
> Though in theory, assuming that the switch is capable of receiving and
> transmitting at wire speed, the maximum amount of buffer it would need
> to deal with a 1Gb/s flow between A and B would be <switch latency>*1Gbit
> (plus a shade) since from the switch's point of view, data-in == data-out,
> irrespective of the window size of the hosts.
Yes, if both hosts are connected at the same speed, no extensive buffering
is needed. However, another usage scenario for such switches is speed
downshift, e.g. 1Gbps uplink -> 100 Mbps host (or 10 Gbps -> 1 Gbps),
where the relation to TCP window size does apply.
With kind regards,
M.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
