<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 1:26 PM, Andy Furniss <span dir="ltr"><<a href="mailto:adf.lists@gmail.com" target="_blank">adf.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Sebastian Moeller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Andy,<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Feb 27, 2017, at 19:02, Andy Furniss <<a href="mailto:adf.lists@gmail.com" target="_blank">adf.lists@gmail.com</a>><br>
wrote:<br>
<br>
Sebastian Moeller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Looking at tc-adv, I would recommend to use “rtt 50” (maybe it is<br>
“rtt 50ms”) which allows to directly explicitly request a new<br>
“interval” (which IIRC is corresponding to the time you allow for<br>
the TCP control loop to react to cake’s ecn-marking/dropping)<br>
“target’ will be calculated as 5% of the explicit interval, in<br>
accordance with the rationale in the codel RFC.<br>
</blockquote>
<br>
50 is certainly better than 10, but still seems to hurt single a<br>
bit even on a close server.<br>
</blockquote>
<br>
Oopps, what I meant to convey is that there is the numeric option<br>
“rtt NNN” that allows to select the exact RTT/interval you believe<br>
to be valid. I picked 50 just because I wanted to give a concrete<br>
example, not because I believe 50 to be correct for your<br>
experiments...<br>
</blockquote>
<br></span>
Ahh, OK.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On more distant servers maybe even more - I am getting results<br>
that are too variable to tell properly at the current time (of<br>
day).<br>
<br>
<a href="http://www.thinkbroadband.com/speedtest/results.html?id=1488216166262542155" rel="noreferrer" target="_blank">http://www.thinkbroadband.com/<wbr>speedtest/results.html?id=1488<wbr>216166262542155</a><br>
<br>
<br>
<br>
<br>
</blockquote></blockquote>
Almost OK, but with 100ms this test usually shows x1 and x6 the same.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://www.thinkbroadband.com/speedtest/results.html?id=1488218291872647755" rel="noreferrer" target="_blank">http://www.thinkbroadband.com/<wbr>speedtest/results.html?id=1488<wbr>218291872647755</a><br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
</blockquote>
Interesting. My mental image is that interval defines the time you<br>
give both involved TCPs to get their act together before escalating<br>
cake’s/codel’s signaling. The theory as far as I understand it says<br>
that the RTT is the lower bound for the time required, so I am not<br>
totally amazed that relaxing that interval a bit increases bandwidth<br>
utilisation at a vert moderate latency cost (if any). The art is to<br>
figure out how to pick the interval (and I believe the codel paper<br>
showed, that at least for codel the exact number is not so important<br>
but the ballpark/ order of magnitude should match).<br>
</blockquote>
<br></span>
Seems to be a repeatable result.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course as we all know ingress shaping is a different beast<br>
anyway and would deserve its own thread.<br>
</blockquote>
<br>
The cool thing is that ingress shaping with all its<br>
“approximateness” (is that a word) works as well as it does ;)<br>
</blockquote>
<br></span>
Yea, though I am always interested in any ingress specific tweaks.<br>
<br>
On my current line I have a 67 meg sync and the ISP buffer seems to<br>
spike to max 80ms then settle to 40 = luxury compared to when I used to<br>
have a 288/576 kbit sync adsl line with a 600ms remote buffer. Ingress<br>
shaping on that was a bit more "interesting", especially as I targeted<br>
latency for gaming. Back then I used to use connbytes and a short head<br>
dropping sfq (needed hack) to get tcp out of (no so) slow start quickly.<br>
<br>
Even on this line I can measure regular (without qos) tcp blips of 70ms<br>
when someone is watching an HD vid on youtube. Streaming is misleading<br>
description for this test at least, blipping would be better :-)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Netflix is working on packet pacing for FreeBSD. After bufferbloat, it's the next big issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sacrificing 6 meg does make it better (bit variable 20 - 40ms), but the<br>
blips still show. The challenge of keeping the remote buffer empty ish<br>
without sacrificing too much speed is an interesting one.<br>
<br>
Until recently I didn't need to care as my ISP did QOS with AFAIK<br>
Ellacoyas. Unfortunately they had a big change in their network and for<br>
reasons unknown it all went pear shaped so they have turned it off.<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
</div></div></blockquote></div><br></div></div>