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