Re: [j-nsp] Tail drop on EX3400

2019-05-30 Thread Saku Ytti
> My guess is that I'll have to create a custom scheduler and apply to > interfaces to be able to have all that buffer space available for basic > Internet... This is actually something we've needed to do on lot of 1RU switches for 20 years. Catalysts at least since 3550 has not shipped with QoS

Re: [j-nsp] Tail drop on EX3400

2019-05-30 Thread Saku Ytti
96ms was based on your proposal that EX4200 is 12MB, which it is not, it's 2.5MB, so it's 20ms @ 1Gbps. If we're talking about uncongested device then the worst case is 10GE => 1GE step down, where you need to potentially queue the tcp window growth to reach 1Gbps. Only reason to queue at 10GE

Re: [j-nsp] Tail drop on EX3400

2019-05-30 Thread Philippe Girard
Thanks everyone for your input, very interesting. Reality is, we have ~300Mbps coming in the 10G port and ~50-100Mbps per customer port at peaks, really, not that much. Also, although tweaking TCP is nice, I can hardly go to each customer of mine telling them to augment their TCP window settings

Re: [j-nsp] Tail drop on EX3400

2019-05-30 Thread Jason Healy
On May 30, 2019, at 2:23 AM, Saku Ytti wrote: > > 12MB / 1Gbps == 96ms. That would be massive buffer. Not if you're Arista... ;-) You're correct that it's 96ms for the 1Gbps side, but if packets are arriving at 10Gbps then that's only 9.6ms (ish) before you run out of buffer. It's the

Re: [j-nsp] Tail drop on EX3400

2019-05-30 Thread Saku Ytti
On Thu, 30 May 2019 at 04:06, Jason Healy wrote: > There really isn't any clever way around it; I think those switches have 12MB > of buffer (or is that the QFX?). Anyway, if you do the math you quickly find > out that works out to like 10ms of traffic, so the switch simply can't buffer >