wow. That is the best dslreports test result for cable I have ever had. with hping3 -2 -d 0 -s 10080 -k -p 80 -i u150 96.120.89.153
http://www.dslreports.com/speedtest/36209937 Without: http://www.dslreports.com/speedtest/36210095 You say a different cablemodem does better without hping3 running? which? :) Most of my production gear is based on an older arris modem (which is quite good), most of my test gear is a bunch of netgear (free) modems and service I got free from my time working for comcast. I haven't got around to springing for a docsis 3.1 modem yet (they are awfully pricy). On Sat, Jul 21, 2018 at 2:37 PM Dave Taht <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> https://lists.bufferbloat.net/listinfo/cake > >> > > > > > -- > > Dave Täht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
