[Cake] Other codel decay issues

[Cake] Other codel decay issues

[Dave Taht]

Codel state variable decay is an issue. I did not poke
into the 8 way set associative cache worked, but...

Queues empty and fill at lower rates as well, you DO
want to reuse the codel queue that was going into in
that case.

Eric settled on about 3 seconds to gc sch_fq; most
codel versions reset their state at 1600ms empty.

You probably want a "fresh" codel queue for each new
flow, or one borrowing from other existing states.

(I actually do like pie sometimes, just measuring the
total queue and then trying to find an ideal drop rate)
-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Cake] Other codel decay issues

[Jonathan Morton]

> On 13 Apr, 2015, at 01:14, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Codel state variable decay is an issue. I did not poke
> into the 8 way set associative cache worked, but...
> 
> Queues empty and fill at lower rates as well, you DO
> want to reuse the codel queue that was going into in
> that case.
> 
> Eric settled on about 3 seconds to gc sch_fq; most
> codel versions reset their state at 1600ms empty.
> 
> You probably want a "fresh" codel queue for each new
> flow, or one borrowing from other existing states.

I took this into account with the set-associative hash design.

The function deliberately tries to keep the same flow in the same queue as much as is reasonable, without flip-flopping a given queue between flows.  The latter is only likely to occur if both flows are fairly sparse, giving Codel little to do on them, or if severe overload is causing collisions.

To help with testing this, I note that the first version of cake was functionally equivalent to fq_codel if you specified “unlimited besteffort” as its options.  Cake3 behaves similarly in this respect, except that now you get the set-associative hash instead of the plain one (and there’s no way to turn that off at runtime).

 - Jonathan Morton