Strict token bucket without fair queuing can cause packetloss bursts for all flows. In my personal experience when dealing with a low(single digit) RTT, I would find that my ex-50Mb connection would accept a 1Gb burst and ACK all of the data. Then the sender would think I had a 1Gb link and keep sending at 1Gb. Around the 200ms mark, there would be a steep slope where all of my traffic would suddenly see ~5% loss for the rest of that second. Once steady state was reached, it was fine. The issue seemed to have a baseline relative to the ratio between the provisioned rate and the burst rate, with a dynamic multiplier not-quite-linearly driven by the link's current utilization. At ~0% average utilization, bursts that lasted longer than the bucket could induce maximum, and not much of an issue past 80%. I could reliably recreate the issue by loading a high bandwidth video on youtube and jumping around the timeline to unbuffered segments. I had anywhere from 6ms to 12ms latency to youtube CDNs depending on the route and which datacenter. Not only could I measure the issue with icmp at 100 samples per second, but I could reliably see issues in-game with either UDP or TCP based games. Simply shaping to 1-2Mb below my provisioned rate and enabling Codel seemed to alleviate the issue into not-noticing. On Sun, Jul 1, 2018 at 4:50 PM Jonas MÃ¥rtensson wrote: > > > On Sat, Jun 30, 2018 at 9:46 AM Pete Heist wrote: > >> >> On Jun 30, 2018, at 8:26 AM, Jonas MÃ¥rtensson >> wrote: >> >>> >>> I played around with flent a bit, here are some example plots: >> >> https://dl.dropbox.com/s/facariwkp5x5dh1/flent.zip?dl=1 >> >> The short spikes are not seen with flent so I'm led to believe these are >> just a result of running the "Hi-Res" dslreports test in a browser. In the >> flent rrul test, up to about 10 ms induced latency can be seen during the >> "powerboost" phase but after that it is almost zero. I'm curious about how >> this is implemented on the ISP side. If anything, sqm seems to induce a bit >> more latency during the "steady-state" phase. >> >> >> You may also want to try running flent with --socket-stats and making a >> tcp_rtt plot. You should see a significant difference in TCP RTT between >> sfq and anything that uses CoDel. >> > > In case anyone is curious I tried this and the tcp rtt plot looks very > similar to the ping rtt plot, i.e. the latencies are the same. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >