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

[Alan Jenkins]

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.

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

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

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

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

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