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

Dave Taht <dave.taht@gmail.com> Thu, 12 March 2015 02:31 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02EB1A89F2 for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 19:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxOA1zOLpwKQ for <aqm@ietfa.amsl.com>; Wed, 11 Mar 2015 19:31:58 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114711A897F for <aqm@ietf.org>; Wed, 11 Mar 2015 19:31:58 -0700 (PDT)
Received: by obcuy5 with SMTP id uy5so12924554obc.11 for <aqm@ietf.org>; Wed, 11 Mar 2015 19:31:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MRMe1ybhiJTYKL1O1j8GnHfo9YUR8sjzFPkGVlwDg5o=; b=EIQY6jjWHmMInCDKWqiTZZoFO1TKKmp1ZNgpCHTpxnzN7jWr11uIQunk4VxHzur5yr q8n0F5rltZJbgIQFcurwnaf/weIJh7/B6NrVLLMWt+LjQrOS8YA+isgnRVQz803covCb MDTkWaVdsNyrW4cGbprM+8E9e4vZ1i1jLGc2LLe99P/b1mxrZ01a1MLnyEayWGXXFyyo u7yUI+XjGim2vJnC28mkvMH11Dl9aLgqcjT4ELp+KzwtbWZWNzbSOyao1yJ8lwd1MNk4 DHfOlkJ+XTwP8HxjZK/m45axR8cwa9sY+7KDFzhSXjr/r+gXQAcCBTD87bv/e5Jjo+xI TKkw==
MIME-Version: 1.0
X-Received: by 10.182.230.132 with SMTP id sy4mr32531516obc.29.1426127517571; Wed, 11 Mar 2015 19:31:57 -0700 (PDT)
Received: by 10.202.51.66 with HTTP; Wed, 11 Mar 2015 19:31:57 -0700 (PDT)
In-Reply-To: <CAA93jw6Bp9eAdmAuiV52+RwtTM3m73Vxc0LQ2qPNpCJAqc1DhA@mail.gmail.com>
References: <CAA93jw59q6sWCfEjD2giY2GbMMTuSBDrAXYQLAir_fnnSoE7Ww@mail.gmail.com> <E7681518-1B51-4E1D-88FF-83811EDA2563@mnot.net> <CAA93jw6Bp9eAdmAuiV52+RwtTM3m73Vxc0LQ2qPNpCJAqc1DhA@mail.gmail.com>
Date: Wed, 11 Mar 2015 19:31:57 -0700
Message-ID: <CAA93jw6WTRot678NSjgk76RKY9=YUmZ0HYjVg5Oox2wC1NuSJA@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/JBVMnRjxch_MnVp1G7brJ7yIN4g>
Cc: "aqm@ietf.org" <aqm@ietf.org>, netalyzr <netalyzr@icsi.berkeley.edu>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [aqm] fixing bufferbloat on bigpond cable...
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 02:32:00 -0000

"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