Re: [Codel] usage of 'count' in codel

[Simon Barber <simon@superduper.net>]

I was thinking the same thing (implement sfq+codel), I'm happy to 
refactor the codel code to be usable both standalone and with sfq, 
unless Eric is already doing it. Another option would be pfifofast + 
codel - perhaps a candidate for the default qdisc?

Simon

On 05/06/2012 10:58 AM, dave taht wrote:
> On 05/06/2012 10:20 AM, Jim Gettys wrote:
>> On 05/06/2012 01:08 PM, Eric Dumazet wrote:
>>> On Sun, 2012-05-06 at 16:51 +0200, Eric Dumazet wrote:
>>>> On Sun, 2012-05-06 at 07:46 +0200, Eric Dumazet wrote:
>>>>> With 60 netperfs
>>>>>
>>>>> Using :
>>>>> c = min(q->count - 1, q->count - (q->count>>4));
>>>>> q->count = max(1U, c);
>>>>>
>>>>> keeps count below 60000
>>>>>
>>>>> qdisc codel 10: dev eth9 parent 1:1 limit 1000p minbytes 1514
>>>>> target 5.0ms interval 100.0ms
>>>>> Sent 12813046129 bytes 8469317 pkt (dropped 575186, overlimits 0
>>>>> requeues 0)
>>>>> rate 202366Kbit 16708pps backlog 160484b 106p requeues 0
>>>>> count 29048 delay 5.7ms drop_next 564us states 8334438 : 7880765
>>>>> 574565 621
>>>>>
>>>>>
>>>> I rewrote the time management to use usec resolution instead of nsec,
>>>> and store it in a u32 field for practial reasons ( I would like to add
>>>> codel on SFQ, so need to replicate the codel object XXX times in
>>>> memory)
>>>>
>>>> More exactly I use 1024 nsec units (to avoid divides by 1000)
>>>>
>>>> And it seems I no longer have crazy q->count.
>>>>
>>>> Either there was a problem with the big/fat time comparaisons, either
>>>> using an u32 triggers a wraparound every 4sec that cleanup the thing.
>>>>
>>>> More to come
>>> No it doesnt work if I have non responsive flows (UDP messages).
>>>
>>> My queue fills, delays are high...
>>>
>>> The time in queue idea is good (We discussed it already), but unlike
>>> RED, codel is unable to force an upper limit (aggressive drops if
>>> delays are way too high)
>> You are presuming that codel is the only thing running; but that's not a
>> good presumption. There may be/is expected to be other fair
>> queuing/classification going on at the same time.
> I think codel is a very viable backend to an fq algo, and solves the
> udp flood problem handily.
>
> and I figure eric is already halfway through ripping red out of
> sfq and adding codel in its place. :)
>
> I've run it against qfq with good results, but more on that later.
>
>> An unreactive UDP flow can always cause trouble. Dropping packets can
>> only be useful if the end points notice and do something about it.
> yes. udp foods are a problem in drop-tail too.
>> I sort of think that having some upper queue time bound makes sense, if
>> only to ensure that TCP's quadratic (un)responsiveness never gets out of
>> hand.
> Well, we had to put in an upper packet limit anyway.
>> But we agreed that having an implementation we could play with to
>> observe reality would likely be better than hand-waving with no
>> experience about how long the queue should be allowed to grow.
> yes.
>
> and it really is awesome in all the versions so far. What
> eric did this morning is LOVELY.
>
>>
>> And can we *please* get this discussion back on the mailing list?
>
> Well, we were afraid we'd found something grievously wrong with codel
> rather than our code, or had missed a 4th state in the machine
>
> All the same, count can grow out of control and something like this
> seems to help, although it's not as smooth on the downside...
>
> /*
> * if min went above target close to when we last went below it
> * assume that the drop rate that controlled the queue on the
> * last cycle is a good starting point to control it now.
> */
> if (codel_time_after(now - q->drop_next, 16 * q->interval)) {
> // u32 c = min(q->count - 1, q->count - (q->count >> 4));
> u32 c = q->count >> 1;
> q->count = max(1U, c);
>
>
> I figure eric will post to the mailing list before he crashes.
>
>> - Jim
>>
>>
>>
>>
>
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel