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

[Dave Taht <dave.taht@gmail.com>]

On Sun, Aug 2, 2015 at 9:04 PM, Benjamin Cronce <bcronce@gmail.com> wrote:
>
>
> On Sun, Jul 26, 2015 at 4:05 PM, Alan Jenkins
> <alan.christopher.jenkins@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.

>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.


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).
>>
>>
>> Alan
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast