[Cake] How to test Cake on TP-Link WDR3600
dave.taht at gmail.com
Sun Aug 2 16:07:35 EDT 2015
On Sun, Aug 2, 2015 at 9:04 PM, Benjamin Cronce <bcronce at gmail.com> wrote:
> 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.
This is one of the exciting-for-research parts of cake, we can actually try
real workloads and measure, rather than just math.
I added the ability to track active flows in the current git head for
the out of tree version.
> 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.
https://team.inria.fr/rap/files/2013/12/KMOR05b.pdf might be helpful to read.
good math. for what is tractable that way, anyway.
> 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).
> Cake mailing list
> Cake at lists.bufferbloat.net
worldwide bufferbloat report:
What will it take to vastly improve wifi for everyone?
More information about the Cake