"cake", if we ever get around to finishing it, gets it down to 1 line of code for outbound, and maybe 1 or 2 for inbound. That said, we probably need a policer for inbound traffic on the lowest end hardware built around fq_codel principles. The design is called "bobbie", and I kept meaning to get around to it for about 3 years now.
That one line (for anyone willing to try the patches) tc qdisc add dev eth0 root cake bandwidth 2500kbit diffserv but back to my open question - how can we get better public benchmarks that accurately detect the presence of AQM and FQ technologies on the link? On Wed, Mar 11, 2015 at 7:23 PM, Dave Taht <[email protected]> wrote: > Sorry, didn't read the thread closely. I made a few suggestions on > that person's gist, as you probably also have downstream bufferbloat > as well, which you can fix (on the edgerouter and openwrt) at speeds > up to 60mbit on those weak cpus using the user-supplied edgerouter gui > for the ingress stuff. The code for doing inbound shaping also is not > that much harder, a simple example for that is in the "ingress" > section on the gentoo wiki here: > http://wiki.gentoo.org/wiki/Traffic_shaping > > (sqm-scripts in openwrt and other linuxen has the logic for this also > built-in) > > It is grand to have helped you out a bit. Thx for all the work on > http/2! How about some ecn? ;) > > On Wed, Mar 11, 2015 at 7:14 PM, Mark Nottingham <[email protected]> wrote: >> Hi, >> >> Just to clarify -- the credit goes to 'saltspork' on that thread, not I :) >> >> Cheers, >> >> >>> On 12 Mar 2015, at 1:11 pm, Dave Taht <[email protected]> wrote: >>> >>> I was very pleased to see this tweet go by today: >>> >>> https://twitter.com/mnot/status/575581792650018816 >>> >>> where Mark Nottingham fixed his bufferbloat on bigpond cable >>> using a very simple htb + fq_codel script. (I note ubnt edgerouters >>> also have a nice gui for that, as does openwrt) >>> >>> But: he does point out a flaw in netanalyzr's current tests[1], in that >>> it does not correctly detect the presence of aqm or FQing on the link, >>> (in part due to not running long enough, and also in not using >>> multiple distinct flows) and like the "ping loss considered harmful" >>> thread last week on the aqm and bloat lists, matching user >>> expectations and perceptions would be good with any public >>> tests that exist. >>> >>> There is some stuff in the aqm evaluation guide's "burst tolerance" >>> tests that sort of applies, but... ideas? >>> >>> [1] I am not aware of any other tests for FQ than mine, which are still >>> kind of hacky. What I have is in my isochronous repo on github. >>> >>> -- >>> Dave Täht >>> Let's make wifi fast, less jittery and reliable again! >>> >>> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb >> >> -- >> Mark Nottingham https://www.mnot.net/ >> > > > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
