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

[Sebastian Moeller <moeller0@gmx.de>]

On Jun 14, 2015, at 21:32 , Alan Jenkins <alan.christopher.jenkins@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? If so, changing sqm-scripts to allow the cake way of specifying overheads gets less urgent… 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…)
	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).

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

> 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?


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.
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel