[Netalyzr] fixing bufferbloat on bigpond cable...
dave.taht at gmail.com
Wed Mar 11 19:31:57 PDT 2015
"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
On Wed, Mar 11, 2015 at 7:23 PM, Dave Taht <dave.taht at gmail.com> 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:
> (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 <mnot at mnot.net> wrote:
>> Just to clarify -- the credit goes to 'saltspork' on that thread, not I :)
>>> On 12 Mar 2015, at 1:11 pm, Dave Taht <dave.taht at gmail.com> wrote:
>>> I was very pleased to see this tweet go by today:
>>> 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, 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?
>>>  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!
>> Mark Nottingham https://www.mnot.net/
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
Let's make wifi fast, less jittery and reliable again!
More information about the Netalyzr