https://www.nanog.org/sites/default/files/20170201_Flach_An_Internet-Wide_Analysis_v1.pdf
On Sat, Jul 21, 2018 at 11:45 AM Dave Taht <[email protected]> wrote: > > 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 -- 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
