[Cerowrt-devel] [Cake] openwrt build available with latest cake and fq_pie

[Sebastian Moeller]

Hi Alan,

On Jun 14, 2015, at 22:43 , Alan Jenkins <alan.christopher.jenkins at gmail.com> wrote:

> On 14/06/15 20:47, Sebastian Moeller wrote:
>> On Jun 14, 2015, at 21:32 , Alan Jenkins <alan.christopher.jenkins at gmail.com> wrote:
>> 
>>> On 14/06/15 17:09, Dave Taht wrote:
>>>>> [...]
>>>> 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…
>> 	Just to be explicit: this combination worked correctly?
> 
> Yes.  I found "cake atm" + "stab overhead" worked fine (and reported it on the cake list).
> 
>> If so, changing sqm-scripts to allow the cake way of specifying overheads gets less urgent…
> 
> If I'm reading the code correctly, sqm-scripts doesn't use _any_ way of setting overhead when qdisc is set to cake.  Maybe I got it wrong though.

	No, you are right, it is not hooked up at all, my bad. Since I still fail t building cake I can not test it, and my track record is bad enough with changes I could have tested, that I want to avoid checking stuff that should work in theory, without any testing ;)

> (other todo would be to add cake to luci-app-sqm, doesn't bother me either way though)
> 
>> Did you by any chance also try to use tic’s stab method to specify overhead and link layer ATM? If that does not work sqm-scripts need a fix quickly anyways (otherwise people will get tangled in our crafty net…)
> 
> Hmm, looks like I didn't record that.  I thought it works but I'm not sure now.

	If you could retest that some of these days I would be delighted, but then cake’s and ht.’s ways of dealing with ATM are more generic than tc stab’s so maybe I can not avoid doing the cake changes anyway...

> 
>> 	I am currently mulling over how to include cake’s more user-friendly way to specify overheads into sqm-scripts, and have no good solution yet. One hack I would like to propose is to attach the “Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully.” to the cake invocation to allow early adopters to pass arbitrary strings to cake, so they can keep the guy. The main issue is that this comes with no safety checks at all, and I have no idea how cake deals with wrong inputs (as I have not been able to build it under opens use 13.2 yet).
>> 
>>> 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.
>> 	So for me the following worked well enough: set the shaper to the exact uplink sync rate as specified in the modem, run RRUL against the nearest server for 300 seconds or so, with the correct overhead and link layer options. On my link latency under load started to increase sharply once the overhead was reduced by a single byte.
>> 	This sensitivity actually allowed me to catch an episode when my ISP had increased the overhead by 4 bytes temporarily (after the RRUL results I re-ran my arm-overhead detector which confirmed the increase by 4 bytes).
> 
> Pretty sure I have to set the rate lower :(.  Maybe an ISP shaper or policer like you mentioned noticing.

	Isn’t it great, every ISP a snow flake ;)

> 
>> 
>>> 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.
>> 	Back of envelop calculation gives an estimate of 2% of downlink-bandwidth as reverse traffic as ACK (before ATM does its dirty work and quantisation).
> 
> It's getting late now :).  But my theoretical calculation was much higher, and it matched the gap in measured bandwidth (tcp goodput) between a 1-way and 2-way test (rrul).  740 and 390 K respectively.
> 
> http://www.dslreports.com/forum/r30046195-FYI-for-general-feedback-on-the-new-speedtest
> 
> that said my calculation assumed 1 ack for each tcp segment (packet).  Apparently 1 ack per 2 segments is also common ("delayed ack") and I didn't look at whether that happened in my test.

	I believe the RFC’s state at least one ACK every two MSSs, and if I look at iftop while running rrul tests (under macosx 10.9.5) i get something close to 2%, but I tried to hedge with the “back of envelop” ;)

> 
>>> My pleasure at understanding this is mitigated by how long it took for the light to dawn :).
>> 	Yeah, I guess you will not shed a tear once ATM goes the way of the dodo?
> 
> I like your jokes.  Don't you know, old technology never dies :-D

	Right you are, this is partly th reason why I think that cake should be able to solve this for unsuspecting users that might be trapped on planet ATM for years to come. (I always wonder whether ATM gear really is nearing EOL or whether it will get a second wind in a less developed market; I certainly hope that it truly dies one of the days, like vampires ATM has its charms and yet the world would be a better place without ;) )

Best Regards
        Sebastian

> 
>> Best Regards
>> 	Sebastian
>> 
>>>> , 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.
>>> 
>