From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BC8EA21F30B for ; Wed, 11 Mar 2015 19:31:58 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so12991131obc.0 for ; 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: References: Date: Wed, 11 Mar 2015 19:31:57 -0700 Message-ID: From: Dave Taht To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "aqm@ietf.org" , netalyzr , bloat Subject: Re: [Bloat] fixing bufferbloat on bigpond cable... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 02:32:27 -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 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 bui= lt-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 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 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=C3=A4ht >>> 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=C3=A4ht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb