[Cake] How to test Cake on TP-Link WDR3600

[Benjamin Cronce]

On Sun, Jul 26, 2015 at 4:05 PM, Alan Jenkins <
alan.christopher.jenkins at gmail.com> wrote:

> On 26/07/15 21:09, Alec Robertson wrote:
>
>> I’ve just updated to the newest trunk release of OpenWRT Chaos Calmer
>> (fresh install) and the SQM QOS from OPKG interestingly does include Cake
>> as a qdisc but neither layer_cake.qos nor piece_of_cake.qos are available
>> as setup scripts.
>>
>> I’m still trying out Cake so I’ll be back soon with some feedback.
>>
>>
> You should find the cake option there does nothing?
>
> It'll only work if you have the "kmod-sched-cake" package providing
> /lib/modules/*/sch_cake.ko.  It's only in Dave's recent experimental builds.
>
> fq_codel is the more supported option and serves the same functions.  If
> you can notice any difference yet, I think we'd love to hear about it.
> Currently I believe the noticeable differences are
>
> 1. if your router has TCP offloads enabled, cake undoes ("peels") it some
> to improve latency.  (Getting this past review for mainline Linux sounds
> increasingly "interesting").
> 2. for networks with many flows, cake works much harder to avoid "hash
> collision" (entirely?), so every flow gets a fair share. fq_codel defaults
> to 1000 hash buckets (but collision probability will increase well before
> that point, see "birthday paradox").
>

I was wondering about this. I'm going off of memory, but I read a paper a
while back that said they tested link speeds from 500Mb/s to 2.5Gb/s and
they saw these same characteristics when sending over 10,000 flows over the
congested link.

1) Never more than 200 flows of data in the queue at any given time
2) Never more than 30 flows with more than one packet in the queue at a time

The birthday attack of all 200 flows into 1000 buckets is pretty bad, but
most of those flows are not greedy at any given moment, it's mostly those
30 you need to worry about. The paper I was reading was talking about 10s
of thousands of flows, so I assume there are many greedy TCP flows, but
only 30 have more than one packet in the queue at a time. Assuming this is
true, I wonder what implications this has and what Cake typically sees. Of
course 500Mb is much faster than most consumer connections, but they stated
they saw no difference in queuing even with a large difference in
bandwidth. Because these were not consumer connections, I assume buffers
were properly sized even if FIFO.

Again, going off of memory, I could have gotten a few things out of
context, but it seemed fairly strait forward.


>
> 1) seems a real concern for some new routers.  If you are affected you
> could add a boot script using ethtool.
>
> The idea is it's not optimal to disable offloads universally... maybe if
> you're sharing a usb drive from the router as well or something.  Having
> cake handle it works as a great default configuration.  (I just suspect
> Linux devs would ask why the feature can't be enabled on other packet
> schedulers, e.g. by using a stackable peeler qdisc).
>
>
> Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20150802/99dd749f/attachment-0002.html>