[Bloat] fixing bufferbloat on bigpond cable...

[Bloat] fixing bufferbloat on bigpond cable...

[Dave Taht]

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

Re: [Bloat] fixing bufferbloat on bigpond cable...

[Mark Nottingham]

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@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/

Re: [Bloat] fixing bufferbloat on bigpond cable...

[Dave Taht]

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@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@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

Re: [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@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@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@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