[Cerowrt-devel] Latest build test - new sqm-scripts seem to work; "cake overhead 40" didn't
Sebastian Moeller
moeller0 at gmx.de
Fri Jun 19 12:41:32 EDT 2015
Hi Alan,
excellent, thanks a million.
On Jun 19, 2015, at 16:44 , Alan Jenkins <alan.christopher.jenkins at gmail.com> 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 <moeller0 at gmx.de> 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 <moeller0 at gmx.de>
>>> wrote:
>>>> Hi Dave,
>>>>
>>>>
>>>> On Jun 18, 2015, at 22:18 , Dave Taht <dave.taht at gmail.com> wrote:
>>>>
>>>>> On Thu, Jun 18, 2015 at 1:04 PM, Sebastian Moeller <moeller0 at gmx.de>
>>>>> wrote:
>>>>>> Hi Dave,
>>>>>>
>>>>>>
>>>>>> On Jun 18, 2015, at 21:33 , Dave Taht <dave.taht at gmail.com> 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 <moeller0 at gmx.de>
>>>>>>> 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
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
More information about the Cerowrt-devel
mailing list