[Codel] failing, bailing

[Dave Taht]

So I got caught up to patch v6 and the latest iproute code from eric
also on this list, got some dinner, and tried again.

Failed.

Lastest kernel patch is here:

https://lists.bufferbloat.net/private/codel/2012-May/000073.html
https://lists.bufferbloat.net/private/codel/2012-May/000076.html

And the current iproute2 patch is here:

https://lists.bufferbloat.net/private/codel/2012-May/000074.html

On Sat, May 5, 2012 at 4:19 PM, dave taht <dave.taht at gmail.com> wrote:
> On 05/05/2012 04:07 PM, Eric Dumazet wrote:
>> This part of Codel seems suspicious (last page )
>>
>> // 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 (now - drop_next<  16.*interval) {
>>        int c = count - 1;
>>        count = c<1? 1 : c;
>> else {
>>        count = 1;
>> }
>>
>>
>> I suggest to replace it by a more conservative algo :
>>
>> // If min went above target close to when we last went below it
>> // assume that sqrt(half) the drop rate that controlled the queue on the
>> // last cycle is a good starting point to control it now.
>> if (now - drop_next<  16.*interval) {
>>        int c = count>>  1;
>>        count = c<1? 1 : c;
>> else {
>>        count = 1;
>> }
>>
> I don't buy it. See previous mail.

OK, but I rented the idea. Against about 30 streams I get this...

$TC -s qdisc show dev eth0
qdisc codel 8007: root refcnt 2 limit 1000p minbytes 1514 target 5.0ms
interval 100.0ms
 Sent 1710602931 bytes 1217897 pkt (dropped 32097, overlimits 0
requeues 520278)
 backlog 112036b 75p requeues 520278
  count 2784 delay 9.0ms drop_next 489us

> count - some_x sure.

Worse.

Then I tried tossing this in everywhere there was a >, to increase
the granularity of the comparison to 10us

static inline int ktime_compare_us10(ktime_t lhs, const ktime_t rhs)
{
        return(ktime_compare(ktime_add_ns(lhs,10000),rhs));
}

need to sanitize all the comparisons tho... but I'm...

Giving up. Calling in the gods. Tossing the preso on my kindle and
calling it a day.

>
>
>> With this change, my q->count max value is 12000
>>
>>
>>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net