From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-020-ewr.mailhop.org [216.146.33.20]) by lists.bufferbloat.net (Postfix) with ESMTP id 34E422E0135 for ; Sun, 13 Feb 2011 12:22:33 -0800 (PST) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id E24BC92FF42 for ; Sun, 13 Feb 2011 20:22:31 +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-12-ewr.dyndns.com (Postfix) with ESMTP id 711E1932FA7; Sun, 13 Feb 2011 20:22:29 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (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 C5C8C5E878; Sun, 13 Feb 2011 13:22:28 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 87A73121ADB; Sun, 13 Feb 2011 13:22:27 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: bloat-devel , bloat@lists.bufferbloat.net Organization: Teklibre - http://www.teklibre.com References: <87lj3hd00r.fsf@taht.net> <874o8jlhjd.fsf@cruithne.co.teklibre.org> Date: Sun, 13 Feb 2011 13:22:27 -0700 In-Reply-To: (Nathaniel Smith's message of "Sun, 13 Feb 2011 10:31:44 -0800") Message-ID: <871v3br8fw.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 Subject: [Bloat] Bufferbloat related patches for the iwl3945 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: Sun, 13 Feb 2011 20:22:33 -0000 Nathaniel Smith beat me to posting patches this weekend. [1] See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/64733 For details. Perhaps this will spark some discussion here and elsewhere. Nathaniel Smith writes: > Thanks for the poke. I just sent the patches. > I guess we'll see if anyone responds this time. > > I actually suspect that the approach I use in the patch is wrong in > the long run, because it needs that magic constant ("2 ms"), and even > then it can't properly take into account task switching latency (if it > takes >2 ms to get back to the driver, then the queue may drain and we > may lose some throughput, but who knows whether that's the case or > not). What would be better would be some way to detect the case where: > -- there were packets waiting at the next level up -- that would have > been queued, except that the driver decided that it had enough packets > queued already -- and then the driver's queue underflowed If we had > this information, then the driver could do a better job of tuning; it > already can measure excess buffer capacity, and then it'd be able to > measure insufficient capacity directly, and adjust its buffer size > accordingly. I think that is a good start. > > If the network layer just had a counter that it incremented every time > its queue transitioned from empty to non-empty or vice-versa, then we > could detect the above situation as: the driver's queue is empty, > incoming packets are choked, and the counter is odd and has the same > value as it did when we last accepted a packet. But it doesn't have > that counter, and I didn't feel inspired to try and get changes > accepted to the generic networking code. > > I think I'd better work on my thesis instead of getting involved in > the bufferbloat list ;-), and similarly am unlikely to follow up much > on the ideas above, but feel free to forward to anyone who might be > interested (or to the list in general). > > Cheers, > -- Nathaniel -- Dave Taht http://nex-6.taht.net 1: In the future I will keep code related stuff on the bloat-devel list