[c-nsp] iSCSI, port buffers, and small switches

[John Gill]

This paper is indeed a great read, it goes over some really good points 
of the buffering and queuing that are commonly misunderstood.

All good points in this thread, I will make one small comment about the 
N5k here if one wanted to compare buffer sizes on paper: The N5k uses 
ingress buffering with virtual output queues. So when you oversubscribe 
a single egress interface, buffers available for use are proportional to 
the number sending to that interface.  It essentially acts like a shared 
buffer.

Regards,
John Gill
cisco


On 7/26/11 4:14 PM, Nick Hilliard wrote:
> On 26/07/2011 19:47, John Gill wrote:
>> The big scenarios you need buffering are speed difference (regardless of
>> average rate!) or many-to-one host at the same time, otherwise you don't
>> need significant buffers at all.
>
> it's still quite common these days to have a 10g path from the san/nas
> to the network, but 1G access from the network to the client machines,
> modelled using a 10G distribution layer switch connected to both the
> san/nas and a bunch of ToR switches. The ToR switches would have 10G
> uplinks, but 1G downlinks; and unless these ToR switches have sufficient
> buffering capabilities, packet loss may occur on the 1G egress path. So
> although cheaper, it can often prove to be false economy. Also, 1GE is
> getting to be quite slow for disk access these days. My 4.5yo laptop
> pushes 180 mb sequential reads, which is way more than 1Gbit/sec.
>
> There's a rather good paper on C3560/C3750 egress qos here (thanks to
> Saku Ytti for the link):
>
> https://supportforums.cisco.com/docs/DOC-8093
>
> But as you point out, you can largely obviate the need for buffering by
> using the same speed throughout the network. It's on this basis that the
> usual models of 10G ToR cut-thru switches make technical sense even
> though they invariably have tiny buffers, e.g. N5K or any of the other
> vendor 10G merchant silicon-based switches.
>
> Nick
>