Hi Alan, excellent, thanks a million.
On Jun 19, 2015, at 16:44 , Alan Jenkins <[email protected]> wrote: > Hi > > I guess I've done the complementary half to Seb's test :). Basically > "cake overhead 40" didn't work, but that's the fault of cake in this > build. Or tc, as Johnathan suggested. (The "cake atm" part seems to > work, as per my previous test). Great! > > "tc qdisc" says "cake overhead 0", as Sebastian noticed. And the test > results show "cake overhead 40" does not give a measurable > improvement. But "tc stab overhead 40" does. > > I ran this test with the updated sqm-scripts and I think they're doing > the right thing. Thanks for testing this, especially as I can not due to a lack of an ADSL-link (and lack of cake actually, last I looked all I could find was cookies in my browser and a promise of pie in my router) > > > Method: > > I used the updated files from sqm-scripts, > > (once I remembered to mark them executable. Lacking that causes a > failure with no error messages, because sqm-scripts checks before > running them :) > > but didn't bother updating & using luci-app-sqm. Ah, okay, I guess I did test this part with Dave’s help, so this should work with the most recent sqm.lua. > > The test was to compare netperf-runner results - ping during combined > upload & download - for "overhead 40" and "overhead 0". I tested both > values of linklayer_adaptation_mechanism. > > I had to repeat 6 times (60s per run for each overhead) because of > random variation in the range of 3-4ms. I alternated "overhead 40" > and "overhead 0" to try and exclude longer-term variation effects. > > With "stab overhead 40", median latency was better by about 3-4ms. > With "cake overhead 40", there is no such effect. Intersting, when I still had a 6M/1M ADSL link, I saw much larger latency under load increases when setting the per packet overhead to small, but I had my egress shaper running at 100% of line rate, so the system was rigged for maximum effect that way. How are your shapers typically set? > > I'm confident of the result. I just need to set up the scripting > capability in flent now. Running this manually takes too long! > Best Regards Sebastian > Alan > > > On 18/06/2015, Sebastian Moeller <[email protected]> wrote: >> >> Not sure I can test functionality, but at least I could confirm the >> following: >> 1) using the tc stab link layer adjustment method with cake could work >> (needs testing, td-d qdisc reports all the right things). >> >> 2) the advanced qdisc option strings are passed to cake now, which might >> increase the potential tester pool. >> 2.1) these option strings are truly dangerous: one typo or invalid keyword >> and cake will not start up in that direction without any notice; “no error >> checking” indeed. >> >> 3) somehow the installed cake version has issues with numeric overheads, or >> at least with reporting them. >> cake will accept “overhead N” arguments so it clearly understands they >> are >> valid (otherwise see 2.1). >> But it does keep reporting “raw” in “tc -d qdisc” while it should report >> some number istead of raw there. >> >> “atm overhead 40” gets reported as “qdisc cake 802d: dev ifb4eth1 root >> refcnt 2 bandwidth 45Mbit besteffort flows atm overhead 0“ >> So clearly something is off with either cake or tc on that host. >> @Jonathan, any idea what this might be caused by? >> >> 4) My changes not made the router go off-line... >> >> 5) I wonder whether we should not give cake its own script cake.qos, that >> would keep simple and simplest more readable and the cake script should be >> refreshingly concise ;) >> >> >>> >>> So you can't count on getting accurate results this way, but can at >>> least test functionality. >> >> The main tests that needed doing, is do the changes from the GUI >> propagate >> into the enabled sqm instances. It seems they do, so my changes are save >> enough for the greater/smaller hard-core tester community. For actual >> functional tests we need an actual ADSL-link where link-layer adjustments >> issues can readily be observed… >> >>> >>> My plan, such as it was, was to get back to 3 source specific gateways >>> but have run into barrier after barrier. >> >> Maybe we should not have “forked” cerowrt before BB was released, by the >> looks of it you could use a barrier breaker. (Sorry can not resist a bad >> pun/joke, was a long day today…) >> >> Best Regards >> Sebastian >> >>> >>> >>> On Thu, Jun 18, 2015 at 1:24 PM, Sebastian Moeller <[email protected]> >>> wrote: >>>> Hi Dave, >>>> >>>> >>>> On Jun 18, 2015, at 22:18 , Dave Taht <[email protected]> wrote: >>>> >>>>> On Thu, Jun 18, 2015 at 1:04 PM, Sebastian Moeller <[email protected]> >>>>> wrote: >>>>>> Hi Dave, >>>>>> >>>>>> >>>>>> On Jun 18, 2015, at 21:33 , Dave Taht <[email protected]> wrote: >>>>>> >>>>>>> My present box under test is at 2601:646:8300:2cba::129 >>>>>>> >>>>>>> You know the default password for ssh. It is also accessible via >>>>>>> https://[2601:646:8300:2cba::129/] >>>>>> >>>>>> Just the joy of being able to play with cake, made me commit a >>>>>> new change ;) This changes a get_cake_lla_string to >>>>>> `get_cake_lla_string` which in turn might actually do something. I want >>>>>> to note that currently this only passes the numerically defined >>>>>> overhead variable from the GUI to the cake call and side steps the >>>>>> issue how to present the symbolic options. I think this should be fine >>>>>> as current cake users should be seasoned enough to just shrug off this >>>>>> slight inconvenience ;) >>>>>> I only noticed that as I just added the tc_stab link layer >>>>>> adjustment method to the cake calls in simple.qos/simplest.qos so that >>>>>> the different methods can be validated against each other (which was >>>>>> helpful when we had issues with HTB’s private link layer adjustments). >>>>> >>>>> My favorite thing with cake is doing a watch tc -s qdisc show dev >>>>> whatever and looking at the sp(arse) statistic under load. My (ietf) >>>>> world is full of people that think 100ms delay is ok, seeing usec >>>>> makes me happy, and knowing that cake is "peeling" apart the often >>>>> huge packets is quite nice also. >>>> >>>> A good to know. >>>> >>>>> >>>>> High on my list now that I am heads down in getting snmpd to work >>>>> again is to somehow parse various outputs to show drop and CE events >>>>> in mrtg and/or cacti. >>>>> >>>>> I do wish I could find ways to make everyone more productive. I could >>>>> put a box up in my co-lo next week, if that would help, but reflashing >>>>> is a problem no matter where I go. >>>>> >>>>>>> >>>>>>> It is one iteration behind jonathon's cake, and one iteration now >>>>>>> behind sebastian. >>>>>> >>>>>> Make that two iterations ;) >>>>> >>>>> K. Me busy. I will try to keep this box up on this ip for as long as I >>>>> can. I had hoped to flash 6 routers this week. >>>> >>>> Ooops, so I just manually hoisted that boxes sqm-scripts and GUI >>>> to my current development state (I overwrote sqm.lua for luck-app-sqm, >>>> and functions.sh under /usr/lib/sqm and added simple_WIP4cake.qos, these >>>> changes should be confined to simple_WIP4cake (the one extra function in >>>> functions.sh is only called by simple_WIP4cake and hence things should >>>> work for you as before)). >>>> I would love to see wether this can be used to set up cake on >>>> eth0, so I would like to ask for permission to test (for all I know a >>>> reboot might be required, so this only works if you are near that box and >>>> there is nothing important using it right now). >>>> >>>> Best Regards >>>> Sebastian >>>> >>>> >>>>> >>>>>> >>>>>> This also means I would love experienced testers for the latest >>>>>> sqm-scripts changes... >>>>>> >>>>>> Best Regards >>>>>> Sebastian >>>>>> >>>>>>> At the moment I am trying to fix snmpd (massive upgrade + musl >>>>>>> support) and won't be touching that box for a while. It IS a dynamic >>>>>>> ipv6 address.... >>>>>>> >>>>>>> Can anyone here push out tc-adv, kmod-* into openwrt's routing repo? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 18, 2015 at 12:19 PM, Sebastian Moeller <[email protected]> >>>>>>> wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I just committed a few cake related changes to luci-app-sqm and >>>>>>>> sqm-scripts in ceropackages 3.10. Mainly it is about passing link >>>>>>>> layer and numeric overhead on to cake (if selected as qdisc), but it >>>>>>>> also passed the two string fields ion the GUI aptly named “Advanced >>>>>>>> option string to pass to the [ingress|egress} queueing disciplines; >>>>>>>> no error checking, use very carefully.” to the [ingress|egress] cake >>>>>>>> instances. This should be helpful in testing cake options under >>>>>>>> openwrt builds. BUT this is totally untested, as I have not managed >>>>>>>> to build cake locally let alone install it. So please, anybody, >>>>>>>> please test the changes and report failure and/or success back. Thank >>>>>>>> you very much in advance. >>>>>>>> >>>>>>>> Best Regards >>>>>>>> Sebastian > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
