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.
Almost OK, but with 100ms this test usually shows x1 and x6 the same.
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
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 :-)
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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake