Re: [Cake] 5ms target hurting tcp throughput tweakable?

[Andy Furniss <adf.lists@gmail.com>]

Sebastian Moeller wrote:
> Hi Andy,
>
>
>> On Feb 27, 2017, at 19:02, Andy Furniss <adf.lists@gmail.com>
>> wrote:
>>
>> Sebastian Moeller wrote:
>>> Looking at tc-adv, I would recommend to use “rtt 50” (maybe it is
>>> “rtt 50ms”) which allows to directly explicitly request a new
>>> “interval” (which IIRC is corresponding to the time you allow for
>>> the TCP control loop to react to cake’s ecn-marking/dropping)
>>> “target’ will be calculated as 5% of the explicit interval, in
>>> accordance with the rationale in the codel RFC.
>>
>> 50 is certainly better than 10, but still seems to hurt single a
>> bit even on a close server.
>
> Oopps, what I meant to convey is that there is the numeric option
> “rtt NNN” that allows to select the exact RTT/interval you believe
> to be valid. I picked 50 just because I wanted to give a concrete
> example, not because I believe 50 to be correct for your
> experiments...

Ahh, OK.

>
>>
>> On more distant servers maybe even more - I am getting results
>> that are too variable to tell properly at the current time (of
>> day).
>>
>> http://www.thinkbroadband.com/speedtest/results.html?id=1488216166262542155
>>
>>
>>
>>
Almost OK, but with 100ms this test usually shows x1 and x6 the same.
>>
>> http://www.thinkbroadband.com/speedtest/results.html?id=1488218291872647755
>
>>
>>
> Interesting. My mental image is that interval defines the time you
> give both involved TCPs to get their act together before escalating
> cake’s/codel’s signaling. The theory as far as I understand it says
> that the RTT is the lower bound for the time required, so I am not
> totally amazed that relaxing that interval a bit increases bandwidth
> utilisation at a vert moderate latency cost (if any). The art is to
> figure out how to pick the interval (and I believe the codel paper
> showed, that at least for codel the exact number is not so important
> but the ballpark/ order of magnitude should match).

Seems to be a repeatable result.

>
>>
>> Of course as we all know ingress shaping is a different beast
>> anyway and would deserve its own thread.
>
> The cool thing is that ingress shaping with all its
> “approximateness” (is that a word) works as well as it does ;)

Yea, though I am always interested in any ingress specific tweaks.

On my current line I have a 67 meg sync and the ISP buffer seems to
spike to max 80ms then settle to 40 = luxury compared to when I used to
have a 288/576 kbit sync adsl line with a 600ms remote buffer. Ingress
shaping on that was a bit more "interesting", especially as I targeted
latency for gaming. Back then I used to use connbytes and a short head
dropping sfq (needed hack) to get tcp out of (no so) slow start quickly.

Even on this line I can measure regular (without qos) tcp blips of 70ms
when someone is watching an HD vid on youtube. Streaming is misleading
description for this test at least, blipping would be better :-)

Sacrificing 6 meg does make it better (bit variable 20 - 40ms), but the
blips still show. The challenge of keeping the remote buffer empty ish
without sacrificing too much speed is an interesting one.

Until recently I didn't need to care as my ISP did QOS with AFAIK
Ellacoyas. Unfortunately they had a big change in their network and for
reasons unknown it all went pear shaped so they have turned it off.