[Cerowrt-devel] Latest build test - new sqm-scripts seem to work; "cake overhead 40" didn't

[Alan Jenkins]

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

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


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.

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.

I'm confident of the result.  I just need to set up the scripting
capability in flent now.  Running this manually takes too long!

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