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

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

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
>
>
>
>