[Codel] Today's cake

[Codel] Today's cake

[Jonathan Morton]

I just put in three quite small tweaks to cake:

1) Codel now has a saturating increment for count, rather than a wrapping one.

2) The active flow counter is now an atomic-access variable.  This is really just an abundance of caution.

3) The overload drop routine should now be somewhat more efficient in most cases, since it iterates over the active flows rather than the entire array.  I haven’t measured how much of a difference it makes in practice, but it should be positive.

Point 1 turns out to matter rather a lot under unresponsive loads, given that count is only 16 bits.

The “50 up 1 down asymmetric” test now produces the desired results for the download stream *without* the need to prioritise the acks; Codel now reaches a steady-ish state where it drops enough of them to keep everything moving, and this leaves more bandwidth in the up direction for the 50 streams.

The version of that test with a prioritised download stream reveals that quite a lot of drops (as well as marks) are still occurring in the 50 streams.  This, to my mind, is a sign of too much aggression in the switch from marking to dropping, but I need to work out the numbers to be more confident about adjusting that.

 - Jonathan Morton

Re: [Codel] [Cake] Today's cake

[Dave Taht]

Just when I thought it was safe to flash a router. Honestly. Your
email landed not less than 5 seconds after I finished a build.

On Tue, Jun 16, 2015 at 10:49 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> I just put in three quite small tweaks to cake:
>
> 1) Codel now has a saturating increment for count, rather than a wrapping one.
>
> 2) The active flow counter is now an atomic-access variable.  This is really just an abundance of caution.

It is not clear to me if this is needed, either.

> 3) The overload drop routine should now be somewhat more efficient in most cases, since it iterates over the active flows rather than the entire array.  I haven’t measured how much of a difference it makes in practice, but it should be positive.

I was thinking that tracking the fattest 3 or so flows would suffice,
there would be constant overhead in keeping that statistic handy and
correct but constant overhead on figuring out where to drop on
overload, also.

>
> Point 1 turns out to matter rather a lot under unresponsive loads, given that count is only 16 bits.
>
> The “50 up 1 down asymmetric” test now produces the desired results for the download stream *without* the need to prioritise the acks; Codel now reaches a steady-ish state where it drops enough of them to keep everything moving, and this leaves more bandwidth in the up direction for the 50 streams.
>
> The version of that test with a prioritised download stream reveals that quite a lot of drops (as well as marks) are still occurring in the 50 streams.  This, to my mind, is a sign of too much aggression in the switch from marking to dropping, but I need to work out the numbers to be more confident about adjusting that.

k. What bandwidth?

I still disagree with you on count/2 because you are trying to hit the
next harmonic, and agree with you that count-1 is unstable, but I will
try to get some data instead.

>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: [Codel] [Cake] Today's cake

[Jonathan Morton]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

>> The “50 up 1 down asymmetric” test now produces the desired results for
the download stream *without* the need to prioritise the acks; Codel now
reaches a steady-ish state where it drops enough of them to keep everything
moving, and this leaves more bandwidth in the up direction for the 50
streams.
>>
>> The version of that test with a prioritised download stream reveals that
quite a lot of drops (as well as marks) are still occurring in the 50
streams.  This, to my mind, is a sign of too much aggression in the switch
from marking to dropping, but I need to work out the numbers to be more
confident about adjusting that.
>
>k. What bandwidth?

100/10 Mbit, no added latency, on a LAN.

I should also check what happens when I add a little latency to the mix.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 913 bytes --]

Re: [Codel] [Bloat] Today's cake

[Eric Dumazet]

On Wed, 2015-06-17 at 08:49 +0300, Jonathan Morton wrote:
> 2) The active flow counter is now an atomic-access variable.  This is really just an abundance of caution.

Certainly not needed.

Qdisc enqueue() & dequeue() are done under qdisc spinlock protection.