Re: [Codel] fq_codel: revenge of the standing queue

[Dave Taht <dave.taht@gmail.com>]

On Tue, Sep 4, 2012 at 1:02 PM, Kathleen Nichols <nichols@pollere.com> 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
>> Codel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel
>>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> 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!"