[Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Dave Taht]

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 <dave.taht at gmail.com> 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 <nospam at ariekanarie.nl> 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 <dave.taht at gmail.com> 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 at lists.bufferbloat.net
> >> 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