<div dir="ltr">

<span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">You're now the third person where I've seen the hping3 trick work, I'm pretty pleased it's with Mr Bufferbloat himself ;)</span><br style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">I figured this out by accident some time ago. I used fq_codel and later cake to keep people happy at a small LAN party where 10 people shared a 40Mbit DOCSIS connection. Year after year we kept renting the same vacation homes, with the same old Cisco EPC3295 cable modems. We used to bring some weird pfsense box with tons of custom game-based rules to keep latencies under control, but we just replaced that with an openwrt box running fq_codel one day, way simpler and better latencies (thank you and the other bufferbloat people!)</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Suddenly one year, my openwrt/cake box was no longer able to keep the latency under control and people started complaining. I noticed that while an upload was running, the latency was fine (despite someone hogging the downstream with big downloads). As soon as the upload stopped, the big download started to cause ping spikes again.</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">After some testing, I was able to use the hping3 trick to send the minimum needed upstream traffic to keep pings low, LAN party saved.<br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Meanwhile on my home connection I used a similar DOCSIS modem. I'd always been able to just shape my connection close to the advertised rates. One day, latencies (and DSLReports bufferbloat score) got bad. Interestingly, flent RRUL results reported lower latencies during the test run than during the idle period before and after the test. Again I could use the same hping3 trick to "fix" it. I've asked the bufferbloat mailing list to see if anyone knew what was going on, but nothing came of it.</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">My ISP kept pushing new DOCSIS modems, so I took my chances despite it using a puma 6 chipset (TG2492LG). This one is fine without the hping trick, just like my old modem used to be.<br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Here's what I learned about some cable modems with my particular ISP (Ziggo, the Netherlands) in my specific region:</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Cisco EPC3212 (DOCSIS 3.0 8x4), used to work fine, now gets big latency spikes regardless of the shaped rate.</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Technicolor 7200 (<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">DOCSIS 3.0</span> 8x4), still works fine.</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Arris <span> </span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">TG2492LG (<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">DOCSIS 3.0</span> 24x8), shaping works just fine, latency is under control, but it has a puma 6 chip which causes latency spikes in TCP and ICMP packets. UDP does not seem to be affected.</span></div>

<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 July 2018 at 00:13, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">wow. That is the best dslreports test result for cable I have ever had.<br>
<br>
with hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 96.120.89.153<br>
<br>
<a href="http://www.dslreports.com/speedtest/36209937" rel="noreferrer" target="_blank">http://www.dslreports.com/<wbr>speedtest/36209937</a><br>
<br>
Without:<br>
<br>
<a href="http://www.dslreports.com/speedtest/36210095" rel="noreferrer" target="_blank">http://www.dslreports.com/<wbr>speedtest/36210095</a><br>
<br>
You say a different cablemodem does better without hping3 running? which? :)<br>
<br>
Most of my production gear is based on an older arris modem (which is<br>
quite good), most of my test gear is a bunch of netgear (free) modems<br>
and service I got free from my time working for comcast.<br>
<br>
I haven't got around to springing for a docsis 3.1 modem yet (they are<br>
awfully pricy).<br>
<div class="HOEnZb"><div class="h5">On Sat, Jul 21, 2018 at 2:37 PM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
><br>
> or, another way we might look at it is there is very little we can do<br>
> as the cmts has to have data in it in order to burst schedule the mac<br>
> for the next string of packets, much like how fq_codel for wifi has<br>
> "one in the hardware, one ready to go", a cmts has at least one in the<br>
> hardware (per channel? a multiple? what?).<br>
><br>
> or I could be on drugs entirely. And this thread did start with<br>
> <a href="http://fast.com" rel="noreferrer" target="_blank">fast.com</a> misbehaving badly regardless of the shaper in place or not,<br>
> which is not what I'm looking at now.  I need to setup a 45ms rtt<br>
> test...<br>
><br>
> anyway, as per your suggestion, the latency gets MUCH better with your<br>
> hping3 idea running, which implies that we've  been fooled all along<br>
> by the rrul test. On the other hand, I think this will hurt other<br>
> cable modems on the same wire. On the gripping hand, I'm happier<br>
> knowing that with a busier network, docsis cable, when shaped, gets<br>
> better, and that I should junk my existing test cablemodem due to the<br>
> persistent spikes I see.<br>
><br>
> I wonder if it's the sent path or the return path shattering latency<br>
> so well? I wonder if hping3 would count against your badwidth cap?<br>
><br>
> going back to trying to figure out why <a href="http://fast.com" rel="noreferrer" target="_blank">fast.com</a> is so gnarly<br>
> On Sat, Jul 21, 2018 at 2:18 PM Arie <<a href="mailto:nospam@ariekanarie.nl">nospam@ariekanarie.nl</a>> wrote:<br>
> ><br>
> > 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:<br>
> ><br>
> > hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 IP-OF-FIRST-OUTSIDE-CABLE-HOP-<wbr>HERE<br>
> ><br>
> > On 21 July 2018 at 22:36, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> >><br>
> >> This is my "inbound trying to shape a cable connection" smoking gun.<br>
> >> The delay curve is the same<br>
> >> shaping the 110mbit cmts down to 85mbit OR 55mbit.<br>
> >><br>
> >> ______________________________<wbr>_________________<br>
> >> Cake mailing list<br>
> >> <a href="mailto:Cake@lists.bufferbloat.net">Cake@lists.bufferbloat.net</a><br>
> >> <a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cake</a><br>
> >><br>
> ><br>
><br>
><br>
> --<br>
><br>
> Dave Täht<br>
> CEO, TekLibre, LLC<br>
> <a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
> Tel: 1-669-226-2619<br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-669-226-2619<br>
</div></div></blockquote></div><br></div>