[Cake] 5ms target hurting tcp throughput tweakable?

[Benjamin Cronce]

On Mon, Feb 27, 2017 at 1:26 PM, Andy Furniss <adf.lists at gmail.com> wrote:

> Sebastian Moeller wrote:
>
>> Hi Andy,
>>
>>
>> On Feb 27, 2017, at 19:02, Andy Furniss <adf.lists at 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=1488
>>> 216166262542155
>>>
>>>
>>>
>>>
>>> Almost OK, but with 100ms this test usually shows x1 and x6 the same.
>
>>
>>> http://www.thinkbroadband.com/speedtest/results.html?id=1488
>>> 218291872647755
>>>
>>
>>
>>>
>>> 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 :-)
>

I have not sampled YouTube data in a while, but the last time I looked it
had packet-pacing issues. With TCP going from idle to full, several times a
second. Not only do you get the issue that TCP will front-load the entire
TCP window all at once, but if the data being transfers fits within the TCP
window, it never learns to back down. If you have a 30ms ping to YouTube,
at 67Mb/s, your window is about 2mbits, which is about 256KiB, which is
about the same size as the request sizes to "stream", last I knew.

Netflix is working on packet pacing for FreeBSD. After bufferbloat, it's
the next big issue.


>
> 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.
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20170228/b0768e6d/attachment.html>