From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-ewr.dyndns.com (mxout-059-ewr.mailhop.org [216.146.33.59]) by lists.bufferbloat.net (Postfix) with ESMTP id 1AF1C2E011F for ; Sun, 20 Feb 2011 07:24:32 -0800 (PST) Received: from scan-02-ewr.mailhop.org (scan-02-ewr.local [10.0.141.224]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id 8045B7E8717 for ; Sun, 20 Feb 2011 15:24:32 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id 23ECA7E8380 for ; Sun, 20 Feb 2011 15:24:27 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:2:21c:25ff:fe80:46f9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 76C095E826 for ; Sun, 20 Feb 2011 08:24:26 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 8DE94122006; Sun, 20 Feb 2011 08:24:25 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Jim Gettys Subject: Re: [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat Organization: Teklibre - http://www.teklibre.com References: <1297907356-3214-1-git-send-email-linville@tuxdriver.com> <1298064074-8108-1-git-send-email-linville@tuxdriver.com> <4D60657E.1080404@freedesktop.org> Date: Sun, 20 Feb 2011 08:24:25 -0700 In-Reply-To: <4D60657E.1080404@freedesktop.org> (Jim Gettys's message of "Sat, 19 Feb 2011 19:51:10 -0500") Message-ID: <87wrkuwwye.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bloat-devel@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 15:24:33 -0000 Jim Gettys writes: > On 02/19/2011 07:37 PM, Nathaniel Smith wrote: >> Actually, a few more comments just occurred to me... >> >> On Fri, Feb 18, 2011 at 1:21 PM, John W. Linville >> wrote: >>> Johannes' comment about tx status reporting being unreliable (and what >>> he was really saying) finally sunk-in. So, this version uses >>> skb->destructor to track in-flight fragments. That should handle >>> fragments that get silently dropped in the driver for whatever reason >>> without leaking queue capacity. Correct me if I'm wrong! >> >> Should we be somehow filtering out and ignoring the packets that get >> dropped, when we're calculating the average packet transmission rate? >> Presumably they're getting dropped almost instantly, so they don't >> really take up queue space and they have abnormally fast transmission >> times, which will tend to cause us to overestimate max_enqueued? They >> should be rare, though, at least. (And presumably we *should* include >> packets that get dropped because their retry timer ran out, since they >> were sitting in the queue for that long.) Possibly we should just >> ignore any packet that was handled in less than, oh, say, a few >> microseconds? The perfect is the enemy of the good. POGE[1] applies. After getting 2 orders of magnitude improvement with the patches thus far... My reaction to the above is that I'd like to get what is being implemented tested by more folk, across more drivers. Me being one of them! I hope to get builds done today for several openwrt devices and my laggy-lagn laptop. > I will note that AQM algorithms that are likely to work will need to > know the actual "goodput" of the link. (This from talking to Van > Jacobson about the problem we face.) I care about AQM, I really do[2]... Certainly exposing more hooks and data to the next layer in the stack from the driver would be good... But I'd like mostly simply to get: A) People using and loving debloated drivers, & more people aware of and fixing the problem... B) The dynamic range available via ethtool to userspace to be vastly increased C) Buffer sizes defaulting to much less, across the board. These are the simplest, most effective, low hanging fruit/fixes. [1] We're making great progress on wireless, how do we make progress on wired? -- Dave Taht http://nex-6.taht.net 1: http://en.wikipedia.org/wiki/Principle_of_good_enough 2: I'll patch SFB into my build and any other of the new AQMs anyone can suggest