On Tue, Sep 4, 2012 at 1:02 PM, Kathleen Nichols <[email protected]> wrote: > > > I can't keep up with the pace here, but I'm compelled to express puzzlement > at the notion that fq_codel gives *longer* standing queues than codel.
I'm not saying that. fq_codel < codel < pfifo_fast, certainly and we don't run into needing floating point on count, and it's totally great. I'm saying that at high numbers of flows we end up with a standing queue in fq_codel. That's it. It would be cool to find a way to drain that swamp more, or understand better what I see, and that was the basic thrust of that long email (that I had been sitting on a week), where I tried to point at what I felt were flawed assumptions regarding temporarily empty queues. Eric views fq_codel as a "codel multiplexor", and I was trying to describe, obviously unsuccessfully, possible ways to do a merger of fq PLUS codel that might work better. >The > opposite happens with sfq_codel which is, I believe, doing the same basic > things as fq_codel (a similar approach to that below for queues/bins that go > empty) except for being packet scheduled rather than byte scheduled. I > see this wonderful, well-controlled behavior without "reverse traffic" > issues. If you run your sfqcodel sim at 10 and 100mbit with 150 bidirectional flows, what do you get? 300? 1000? > This is why I think Eric's work on this rocks. I think it rocks too. Most of my own battle of late has been with uTP. > > imho, > Kathie I'm going to crawl back under my rock now. > > > On 9/4/12 11:50 AM, Eric Dumazet wrote: >> On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: >> >>> 2) New flows >>> >>> The next issue (at these 10 and 100Mbit rates) is the "new flow" idea >>> in fq_codel. It is VERY useful pushing sparse flows to the fore of the >>> queues, and also provided a boost to long RTT flows. However at high >>> levels of occupancy and low bandwidth, flows empty their queue >>> rapidly, become "new flows", and then mislead codel for that flow into >>> resetting itself again, since we end up with a short delay for the >>> re-entrance. This isn't a particularly horrible behavior, but as my >>> own hope for this feature was to make voip better primarily, and >>> everything else we got from it was a bonus. >>> >>> TSQ really made this oddity show up big. I think on routed traffic it >>> will be less of an issue. >> >> This is simply not true, and based on misunderstanding on what does >> fq_codel. >> >> A flow never leaves the new flow list before doing a full RR cycle in >> old flow list (even without any packet in this flow) >> >> _IF_ we did a full RR cycle, then we accumulated a full quantum of >> credit, and lost our rank the 'fq_codel RR queue' (the combination of >> the 2 internal queues, new and old) >> >> Therefore, we allow the flow to be queued in 'new flow', to recover a >> bit of the lost rank in queue. >> >> Basically you dont interpret correctly the 'new_flow_count' counter. >> >> It means almost nothing at all, since for a given TCP flow, we _can_ >> increment this counter several time. >> >> >> >> _______________________________________________ >> Codel mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/codel >> > > _______________________________________________ > Codel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/codel -- Dave Täht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!" _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
