I was off in the cheap seats watching,

https://www.youtube.com/watch?v=LdjavTiMrs0&feature=youtu.be&t=1h10m3s

saying "yes, for ghu's sake, back off half on ecn - or more! And if
you are going to try defeating policers, despite the desperate reasons
for them to exist... it's time to come up with a policer that will
fool your algorithm enough so the gamer downstairs stops screaming in
frustration!"

and then there was the aqm talk where they tried to move the setpoint
so the link was always buffered, rather than trying to hit the
artificially small buffer size and back off... (actually I liked this
talk because you can also try configuring the setpoint to where it was
below capacity)
On Sat, Jul 21, 2018 at 11:38 AM Dave Taht <[email protected]> wrote:
>
> On Sat, Jul 21, 2018 at 11:37 AM Dave Taht <[email protected]> wrote:
> >
> > On Sat, Jul 21, 2018 at 11:23 AM Arie <[email protected]> wrote:
> > >
> > > It does.
> >
> > well, one approach seems to be to police as per that bug report at say
> > 90-95% of the actual inbound rate, while shaping at 85%... or some
> > combination thereof.
> >
> > figuring out the "burst" value is tricky, of course, but I'd much
> > rather let the queues build up in cake than the cmts, and putting a
> > brick wall there at this point in the internet's evolution seems like
> > a start.
> >
> > this morning I spent watching ietf preso after preso "accept" that
> > 100ms of queuing delay and pdv was acceptible, then showing tests with
> > 50 packet buffers showing that things like BBR worked ok at 100mbit,
> > when... well... here I am at hundred mbit, with 300+ms of inherent
> > queuing delay on the cable downlink, that shapes down nicely using
> > cake vs cubic to 5-40, looking at the carnage. I *don't like* policers
> > (at least, not what's deployed today), and the BBR folk don't like
> > them either... but they seem necessary if overly aggressive transports
> > (as netflix's appears to be, also) exist.
> >
> >
> > >
> > > On 21 July 2018 at 20:02, Dave Taht <[email protected]> wrote:
> > >>
> > >> In other news:
> > >>
> > >> https://github.com/tohojo/sqm-scripts/issues/68
> > >>
> > >> does the ER4 have act_police?
> > >>
> > >> On Sat, Jul 21, 2018 at 10:55 AM Arie <[email protected]> wrote:
> > >> >
> > >> > It's Ziggo NL/Liberty Global. I'm surprised by the reported latency in 
> > >> > the fast.com test. Both the site and the flent ping test report about 
> > >> > the same 60-ish ms.  DSLReports and flent RRUL report way more 
> > >> > bufferbloat, so I guess those stress my connection more than fast.com
> > >> >
> > >> >
> > >> > On 21 July 2018 at 19:45, Dave Taht <[email protected]> wrote:
> > >> >>
> > >> >> Thank you. At least for your ISP (?), at 250mbit, you can hold the
> > >> >> damage down to something reasonable, and certainly you are winning big
> > >> >> on the upload.
> > >> >>
> > >> >> Good to know the ER4 can keep up, also.
> > >> >> On Sat, Jul 21, 2018 at 10:36 AM Arie <[email protected]> wrote:
> > >> >> >
> > >> >> > Unshaped reno attached.
> > >> >> >
> > >> >> > On 21 July 2018 at 19:27, Dave Taht <[email protected]> wrote:
> > >> >> >>
> > >> >> >> Yours is not as horrific as mine in either case.
> > >> >> >>
> > >> >> >> Can you provide an unshaped result as well?
> > >> >> >>
> > >> >> >>
> > >> >> >> On Sat, Jul 21, 2018 at 10:24 AM Arie <[email protected]> 
> > >> >> >> wrote:
> > >> >> >> >
> > >> >> >> > Two more data points. Shaped my connection to 250Mbit out of the 
> > >> >> >> > advertised 250Mbit (my usual setting) and shaped to 200Mbit out 
> > >> >> >> > of the 250Mbit. This is a pre-linux-net-next cake running on an 
> > >> >> >> > Edgemax ER4 with kernel 3.10.107-UBNT.
> > >> >> >> >
> > >> >> >> > The regular spikes in ICMP ping is due to the crappy Puma 6 
> > >> >> >> > chipset in the cable modem. UDP is not affected.
> > >> >> >> >
> > >> >> >> > On 21 July 2018 at 19:20, Georgios Amanakis 
> > >> >> >> > <[email protected]> wrote:
> > >> >> >> >>
> > >> >> >> >> On Sat, 2018-07-21 at 09:09 -0700, Dave Taht wrote:
> > >> >> >> >> >
> > >> >> >> >> > 1) Can someone else on a cablemodem (even without the latest 
> > >> >> >> >> > cake,
> > >> >> >> >> > this happens to me on older cake and fq_codel) try this test?
> > >> >> >> >> >
> > >> >> >> >>
> > >> >> >> >> I just tried this on my cable comcast connection. I set ingress 
> > >> >> >> >> to ~80%
> > >> >> >> >> of what fast.com reports when no shaper is in place.
> > >> >> >> >>
> > >> >> >> >> #tc qdisc add dev ens4 root handle 8011 cake bandwidth 
> > >> >> >> >> 16000kbit dual-
> > >> >> >> >> dsthost docsis ingress
> > >> >> >> >> #tc qdisc add dev ens3 root handle 8012 cake bandwidth 2500kbit 
> > >> >> >> >> dual-
> > >> >> >> >> srchost nat docsis ack-filter
> > >> >> >> >>
> > >> >> >> >> I got the same result as you. This is using latest cake.
> > >> >> >> >>
> > >> >> >> >> Georgios
> > >> >> >> >>
> > >> >> >> >> _______________________________________________
> > >> >> >> >> Cake mailing list
> > >> >> >> >> [email protected]
> > >> >> >> >> https://lists.bufferbloat.net/listinfo/cake
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> > _______________________________________________
> > >> >> >> > 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
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> 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
>
>
>
> --
>
> 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

Reply via email to