From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-132-ewr.mailhop.org [216.146.33.132]) by lists.bufferbloat.net (Postfix) with ESMTP id 78BF22E0271 for ; Tue, 15 Mar 2011 12:02:01 -0700 (PDT) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 92C3A6F75CD for ; Tue, 15 Mar 2011 19:02:00 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 70.61.120.58 Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 362C66F6B13 for ; Tue, 15 Mar 2011 19:01:55 +0000 (UTC) Received: from uucp by smtp.tuxdriver.com with local-rmail (Exim 4.63) (envelope-from ) id 1PzZVB-0005wU-Bs; Tue, 15 Mar 2011 15:01:53 -0400 Received: from linville-8530p.local (linville-8530p.local [127.0.0.1]) by linville-8530p.local (8.14.4/8.14.4) with ESMTP id p2FIVC9d012201; Tue, 15 Mar 2011 14:31:12 -0400 Received: (from linville@localhost) by linville-8530p.local (8.14.4/8.14.4/Submit) id p2FIVB9G012199; Tue, 15 Mar 2011 14:31:11 -0400 Date: Tue, 15 Mar 2011 14:31:11 -0400 From: "John W. Linville" To: Rick Jones Message-ID: <20110315183111.GB2542@tuxdriver.com> References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1300212877.2087.2155.camel@tardy> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? 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: Tue, 15 Mar 2011 19:02:01 -0000 On Tue, Mar 15, 2011 at 11:14:37AM -0700, Rick Jones wrote: > On Tue, 2011-03-15 at 10:59 -0700, Don Marti wrote: > > begin Jonathan Morton quotation of Tue, Mar 15, 2011 at 06:47:17PM +0200: > > > On 15 Mar, 2011, at 4:40 pm, Jim Gettys wrote: > > > > > > > There is an interesting question about what "long term minimum" means here... > > > > > > VJ does expand on that in "RED in a different light". He means that the relevant measure of queue length is to take the minimum value over some interval of time, say 100ms or 1-2 RTTs, whichever is longer. The average queue length is irrelevant. The nRED algorithm in that paper proposes a method of doing that. > > > > It seems like a host ought to be able to track the > > dwell time of packets in its own buffer(s), and drop > > anything that it held onto too long. > > > > Timestamp every packet going into the buffer, and > > independently of any QoS work, check if a packet is > > "stale" on its way out, and if so, drop it instead of > > sending it. Is this in use anywhere? Haven't seen > > it in the literature I've read linked to from Jim's > > blog and this list. > > Are there any NICs setup to allow (efficient) removal of packets from > the transmit queue (the one known to the NIC) once they have become > known to the NIC? I'm not a driver writer (I've only complained to them > that their drivers were using too much CPU :), but what little I've seen > suggests that the programming models of most (all?) NICs are such that > they assume the producer index only ever increases (modulo the queue > size)... Or put another way, the host giveth, but only the NIC taketh > away. Right. This is more-or-less what I was driving-at with the various versions of my eBDP patches. Once you hand the frame to the device, you have no more control over it (at least for the devices I know about today). All I can see that you can do is to evaluate how quickly (i.e. how low latency) the device is moving those frames it has been given, and then appropriately throttle the amount of frames you continue to give the device. The question is how to do that evaluation, which presumably involves some sort of timestamp. How that evaluation should guide the throttling is also a question. This is something that I think a lot of the discussion about qdiscs is missing. Controlling the queue on the host is great, and there is no point in maintaining long queues on the host. But the queues on some devices are already huge. If you don't throttle _both_ the _enqueue_ and the _dequeue_, then you could be keeping a nice, near-empty tx queue on the host and still have a long, bloated queue building at the device. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.