good discussion. the tl;dr - nothing i can do about it. right?
On Thu, May 2, 2013 at 2:51 PM, Michael Loftis <mlof...@wgops.com> wrote: > 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 <joe...@bogus.com> wrote: >> On 5/2/13 1:24 PM, Benny Amorsen wrote: >>> >>> joel jaeggli <joe...@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@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 > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
