On 14/06/15 17:09, Dave Taht wrote:
On Sun, Jun 14, 2015 at 8:53 AM, Alan Jenkins
<alan.christopher.jenk...@gmail.com> wrote:
On 13/06/2015, Dave Taht <dave.t...@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.
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
