On Jun 14, 2015, at 21:32 , Alan Jenkins <[email protected]>
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
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
