[j-nsp] ex4500 best-effort drops nowhere near congested

[Michael Loftis]

I was finally able to get this explained via a third party who designs
these things ...

Basically in S&F you have an input and output queue, per port.  When
port 1 sends to port 2 frames are moved from 1's input queue to 2's
output queue. If 2's out queue fills, it blocks back into 1's input
queue.  This causes drops not only for frames destined for port 2 but
unrelated frames as well.  In CT mode they get rid of the input queue,
and use that space for the output.  When a port's output queue fills,
drops for that port still happen, but drops for other, unaffected
ports, now do not happen.  CT mode also means the frame is transmitted
much earlier in the 1G-1G and 10G-1G modes (as soon as the ethernet
header is there) when there's no congestion.  So frames w/o an
interframe gap aren't as problematic either (which is the case
sometimes for microburst drops, insufficient interframe gap for the
CRC computation and the switching to occur before buffers fill)

Atleast now I understand how/why it improves things more than just
deeper buffers.  Basically unrelated traffic is unaffected, whereas
with S&F mode, unrelated traffic can get backed up and lots of frames
get dropped that have nothing to do with the actual bottleneck.




On Thu, May 2, 2013 at 2:22 PM, joel jaeggli <joelja at bogus.com> wrote:
> On 5/2/13 1:24 PM, Benny Amorsen wrote:
>>
>> joel jaeggli <joelja at bogus.com> writes:
>>
>>> There's literally no options in between. so a 1/10Gb/s TOR like the
>>> force10 s60 might have 2GB of shared packet buffer, while an like an
>>> arista 7050s-64 would have 9MB for all the ports, assuming you run it
>>> as all 10Gb/s rather than 100/1000/10000/40000 mixes of ports it can
>>> cut-through-forward to every port which goes a long way toward
>>> ameliorating your exposure to shallow buffers.
>>
>> Why does cut-through help so much? In theory it should save precisely
>> one packets worth of memory, i.e. around 9kB per port. 500kB extra
>> buffer for the whole 50-port switch does not seem like a lot.
>
>
> Until there's contention for the output side, you should only have one
> packet in the output queue at a time for each port on a cut through switch.
> which is like 96K of buffer for 1500 byte frames on a 64 port switch
>
> Store and forward means you hold onto the packet a lot longer mechanically
> even if nominally you are able to forward at line rate so long as there's
> always a packet in the ouput queue to put on the wire. consider that the
> fastest cut-through 10Gb/s switches now are around .4usec and your 1500 byte
> packet takes ~1.2usec to arrive.
>
> when adding rate conversion, consider that when having a flow come from a
> 10Gb/s to 1Gb/s port that another 1500byte packet can arrive every ~1.2usec
> but you can only clock them back out every 12usec. jumbos just push the
> opportunities to queue for rate conversion out that much furthure
>
>
>
>> Lots of people say that cut-through helps prevents packet loss due to
>> lack of buffer, so something more complicated must be happening.
>>
>>
>> /Benny
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler