or, another way we might look at it is there is very little we can do as the cmts has to have data in it in order to burst schedule the mac for the next string of packets, much like how fq_codel for wifi has "one in the hardware, one ready to go", a cmts has at least one in the hardware (per channel? a multiple? what?). or I could be on drugs entirely. And this thread did start with fast.com misbehaving badly regardless of the shaper in place or not, which is not what I'm looking at now. I need to setup a 45ms rtt test... anyway, as per your suggestion, the latency gets MUCH better with your hping3 idea running, which implies that we've been fooled all along by the rrul test. On the other hand, I think this will hurt other cable modems on the same wire. On the gripping hand, I'm happier knowing that with a busier network, docsis cable, when shaped, gets better, and that I should junk my existing test cablemodem due to the persistent spikes I see. I wonder if it's the sent path or the return path shattering latency so well? I wonder if hping3 would count against your badwidth cap? going back to trying to figure out why fast.com is so gnarly On Sat, Jul 21, 2018 at 2:18 PM Arie wrote: > > I had a similar issue with my previous cable modem, whatever I shaped to didn't matter, I still had long delays. I "fixed" it by continuously sending a stream of empty UDP packets upstream: > > hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 IP-OF-FIRST-OUTSIDE-CABLE-HOP-HERE > > On 21 July 2018 at 22:36, Dave Taht wrote: >> >> This is my "inbound trying to shape a cable connection" smoking gun. >> The delay curve is the same >> shaping the 110mbit cmts down to 85mbit OR 55mbit. >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >> > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619