[Bloat] fixing bufferbloat on bigpond cable...

[Dave Taht]

"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 <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:
> 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 <mnot at mnot.net> 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 <dave.taht at gmail.com> 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