From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-24-ewr.dyndns.com (mxout-123-ewr.mailhop.org [216.146.33.123]) by lists.bufferbloat.net (Postfix) with ESMTP id 903092E016E for ; Sat, 19 Feb 2011 16:51:16 -0800 (PST) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id D64195CBEFE for ; Sun, 20 Feb 2011 00:51:15 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.62.80 Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id 7C4165CB8EC for ; Sun, 20 Feb 2011 00:51:11 +0000 (UTC) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id A0q21g00D1GhbT8580rCYa; Sun, 20 Feb 2011 00:51:12 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta07.westchester.pa.mail.comcast.net with comcast id A0rB1g00a0hvpMe3T0rB69; Sun, 20 Feb 2011 00:51:12 +0000 Message-ID: <4D60657E.1080404@freedesktop.org> Date: Sat, 19 Feb 2011 19:51:10 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat-devel@lists.bufferbloat.net Subject: Re: [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat References: <1297907356-3214-1-git-send-email-linville@tuxdriver.com> <1298064074-8108-1-git-send-email-linville@tuxdriver.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Feb 2011 17:05:18 -0800 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 00:51:16 -0000 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? 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.) - Jim