[Codel] usage of 'count' in codel

[Dave Taht]

On Sun, May 6, 2012 at 11:15 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Sun, 2012-05-06 at 13:20 -0400, Jim Gettys wrote:
>
>
>
>> 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.
>
> Even with normal tcp flows, codel is not responsive enough and too
> conservative as is.
>
> drop_next = control_law(drop_next)   with interval/sqrt(count)
> increments ?
>
> Something is _really_ wrong.
>
> Thats few drops per second when we need far more than this.
>
> interval = 100ms so you need count = 10000 to reach the rate of one drop
> per ms, regardless of the link capacity.

with the >>1 change.

At 100Mbit I see observed delays that aren't bad, and queue lengths
that are quite nice.

That's with ethernet ratcheted down to 100Mbit with ethtool,
no TSO/GSO with BQL.

1 netperf, 5ms delay on ping RTT
30, about ~12ms

And in both cases the box on the other end is in drop tail.

I don't trust htb at this point, if that's what you are using?

qdisc codel 8007: root refcnt 2 limit 1000p minbytes 1514 target 5.0ms
interval 100.0ms
 Sent 5995574344 bytes 3975635 pkt (dropped 145097, overlimits 0
requeues 1842324)
 backlog 86298b 58p requeues 1842324
  count 4549 delay 6.7ms drop_next 580us

What do you see at 10GigE with like 60 netperfs?

(god, can you even drive 10GigE that hard? me is jealous of hardware.
 I CAN get to where I can drive GigE now, I just want to update both
 sides of the connection to be codel capable, and am waiting on a
 more final patch)


>
> control loop has no input on time of residence of packets.
>
>
>



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