Benjamin Cronce wrote:
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.
Interesting, I guess to some extent client behavior plays a part as well.
I did another test with the same vid looking with a live ping monitor
and "stats for nerds" on. In this case the spacing was 2 to 4 seconds,
with the ping spikes matching the display showing buffer fills.
I guess just changing the buffer watermarks to do more smaller reads
would also be helpful in this case.
Pinging at 10pps shows the spikes last 0.2 to 0.3 seconds on my 67mbit
line. The CDN the data is coming from is only 9ms away from me.
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
