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

[Sebastian Moeller <moeller0@gmx.de>]

Hi Alan,

excellent, thanks a million.

On Jun 19, 2015, at 16:44 , Alan Jenkins <alan.christopher.jenkins@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@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@gmx.de>
>>> wrote:
>>>> Hi Dave,
>>>> 
>>>> 
>>>> On Jun 18, 2015, at 22:18 , Dave Taht <dave.taht@gmail.com> wrote:
>>>> 
>>>>> On Thu, Jun 18, 2015 at 1:04 PM, Sebastian Moeller <moeller0@gmx.de>
>>>>> wrote:
>>>>>> Hi Dave,
>>>>>> 
>>>>>> 
>>>>>> On Jun 18, 2015, at 21:33 , Dave Taht <dave.taht@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel