On Mon, Feb 27, 2017 at 1:26 PM, Andy Furniss wrote: > Sebastian Moeller wrote: > >> Hi Andy, >> >> >> On Feb 27, 2017, at 19:02, Andy Furniss >>> 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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >