[Codel] usage of 'count' in codel

[Jim Gettys]

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.

An unreactive UDP flow can always cause trouble.  Dropping packets can
only be useful if the end points notice and do something about it.

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

And can we *please* get this discussion back on the mailing list?
                    - Jim