> On 3 Nov, 2015, at 18:22, Jeff Weeks <[email protected]> wrote: > > I believe that means 'count' has to reach some nearly impossibly high value > of (100ms/5198ns)^2 == 370,107,128 > > I say nearly impossible, because it will take minutes (hours?) to get that > high (if my math is correct, it'll take over 17 seconds just to reach 7500).
Note that since count increments on every signal given (every packet dropped, in this case), it will increment faster as time goes on, as long as there is a sufficient packet frequency to support it (as there is in this case). However, even 17 seconds is obviously too slow to control the buffer. > In the meantime, the queue *isn't* being effectively managed, as packets with > extremely high latencies will be transmitted for far too long. The problem is that you have an unresponsive flow here. Codel is designed to give adequate congestion signals to *responsive* flows that require only one signal per RTT. Unresponsive flows are instead caught by the buffer limit, causing hard packet drops. This also means that where a responsive flow and an unresponsive flow share the same buffer, Codel doesn’t perform very well; the responsive flow backs off while the unresponsive flow continues to saturate the buffer. (This is also what happens, intentionally, with uTP and standard TCP in a dumb FIFO.) This is fixed if you combine Codel with flow isolation (ie. FQ), since then the responsive and unresponsive flows do not share the same buffer. When the buffer limit is reached, only the longest queue is culled, and this will be the unresponsive flow. - Jonathan Morton _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
