Hi Maciej,
On Feb 25, 2014, at 15:05 , Maciej Soltysiak <[email protected]> wrote: > On Tue, Feb 25, 2014 at 1:08 PM, Sebastian Moeller <[email protected]> wrote: >> TL:DR version, netalyzr probes a buffer depth that while existing has >> not much relevance on the latency behavior under load for cerowrt. > Yes, it doesn't have much relevance for latency where fq_codel or > similar are employed. Exactly. > But where it's not (or where fq_codel is defeated by DOS style > traffic), it seems this comes back as a meaningful metric. That is what I thought as well initially,. But then (I think Eric D explained) if the system is under a DOS attack we have more severe problems at hand than ping latency ;) Think about it that way, if the flood saturates our uplink, fq_codel will sooner or later reign it in anyway, and we only see a temporary glitch in latency performance (during the time the queue stays in tail-drop or so). If the DOS attack is coming from the outside against our system we are hosed anyway, as a the upstream CMTS/DSLAM?BRAS buffers will fill up over which we have no control (as typically the ingress of a DSLAM is much greater than the egress to a specific line so there is going to be an normally temporary queue). I think during a DOS all hops with ingress-from-DOS > egress-to-destination will see buffers filing up... So my current thinking is it is nice to have some buffering against large swings in available bandwidth to smooth out the traffic a bit. On the topic of the limit parameter I want to add, that I see the most relevant part of limit to keep cerowrt out of out-of-memory conditions which will cause the unit to reboot. So ideally the total amount of buffering in the system stays low enough so the box does not go belly-up. > In the end > codel is workaround for overbuffering, which is not being removed very > hastily. I beg to differ, once the buffer management gets smart buffers turn from liability to a boon ;) Best Regards Sebastian > > Best regards, > Maciej _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
