[Cake] openwrt build available with latest cake and fq_pie
alan.christopher.jenkins at gmail.com
Sun Jun 14 15:32:03 EDT 2015
On 14/06/15 17:09, Dave Taht wrote:
> On Sun, Jun 14, 2015 at 8:53 AM, Alan Jenkins
> <alan.christopher.jenkins at gmail.com> wrote:
>> On 13/06/2015, Dave Taht <dave.taht at gmail.com> wrote:
>>> Hopefully, by creating a "tc-adv" package (now in ceropackages) we are
>>> nearly at the last step for being able to do builds out of the main
>>> openwrt tree. I am puzzled as to how to correctly override the default
>>> "tc" package, but at least this built and worked for me the first
>>> so you can kill any local mods to the iproute2 package in your own
>>> openwrt builds, and merely add tc-adv to your own build instead, and
>>> build kmod-sched-fq_pie and kmod-sched-cake, and walla!
>>> assuming this is now correct, the next step would be to push tc-adv
>>> into some mainline openwrt repo (routing?) and get it and the kmod-*
>>> stuff built regularly out of their build system. (and then! yea! try
>>> some faster boxes like the linksys ac1900 and see what new breaks!)
>>> Anyway, my barely tested latest build (cake works, at least) is at here:
>>> This also includes the latest cake, although I disagree with jonathon
>>> about the count/2 mod, might as well test.
>> New build still works for my link :). (15/1M dsl in the UK).
>> If I want to test cake continuously, I'll need to fix sqm-scripts to
>> pass the cake ATM options. I switched back to fq_codel for now (that
>> worked as well).
> Patches gladly accepted (tc-adv now does parse the new keywords I
Yes to both. I'd already tested "cake atm" + "stab overhead". This
time I was dropping "stab" and using "cake atm overhead 44", which tc
Sigh, I forgot the main reason I watched for a second build. To be sure
of "cake overhead" I really need to retest closer to the link speed. I
have a specific method for it.
The test is whether it matches "tc stab overhead" in allowing higher
rates/lower latency on RRUL. As RRUL saturates the uplink, you have to
account for high ATM overhead on the TCP ACK packets there. And the
bandwidth consumed by ACKs (and their overhead) is significant on the
uplink because of the asymmetric link rate. My pleasure at
understanding this is mitigated by how long it took for the light to
> , and we really, really, really do need to confirm that the atm
> code works in every circumstance.
I'm still with you :), I'll have another go in a few days. I've got
some pretty monitoring (smokeping) now, for if I get cake running
permanently. It doesn't seem particularly sensitive to this stuff
but it should show any massive screwup in the rate-limiter :).
 it seems my link is already relatively good & my usage is relatively
More information about the Cake