[Cerowrt-devel] [Cake] openwrt build available with latest cake and fq_pie

[Alan Jenkins]

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
>>> time.
>>>
>>> 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:
>>>
>>> http://snapon.lab.bufferbloat.net/~cero3/lupin/ar71xx/
>>>
>>> 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
> think)

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

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 
dawn :).

> , 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[1] 
but it should show any massive screwup in the rate-limiter :).

Alan

[1] it seems my link is already relatively good & my usage is relatively 
undemanding.