From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-034-iad.mailhop.org [216.146.32.34]) by lists.bufferbloat.net (Postfix) with ESMTP id 963FA2E0392 for ; Tue, 15 Mar 2011 16:12:27 -0700 (PDT) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id E937637087B for ; Tue, 15 Mar 2011 23:12:23 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.171 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id A0760370811 for ; Tue, 15 Mar 2011 23:12:23 +0000 (UTC) Received: by wyb32 with SMTP id 32so1342038wyb.16 for ; Tue, 15 Mar 2011 16:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=AnijGZ/GjdaZoFO/D5dS4Ay2zxd8P5gA3AFmi2dk6bg=; b=k0Lyd2AtLpe0EmbGAla5pTSJ+0BoeDxfWuYuJ0L0x0jHqXdMg8n8tmqV/UMj/xh0el V9fCv5Ad+J0L3JugclDSq1ovzr5GQ5mxODzBIeEcND94KH+fUvfnySs8peRl1NHIag0b y1TUxHcpnTO7UswDjiVWDTmksUvSjPAE+lJVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YuuacXTZ0+4h5F3Zdyrc5TLIps9g1oJWCfjg1vY+0BPm2VHap+gZBrPjU7JLdizFrc TLLkHczGhOs1iuifOi0llceB/cDKYUSK12sFR9Bj/4upxGVagEdR8muXdIzpCRkww1aj tXqgbI8CwR3XAyO9UwBK1TP4bfi2Wdw74jxvw= Received: by 10.216.25.210 with SMTP id z60mr4169240wez.104.1300230742802; Tue, 15 Mar 2011 16:12:22 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id k76sm206953wej.43.2011.03.15.16.12.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 16:12:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <1300229578.2565.29.camel@edumazet-laptop> Date: Wed, 16 Mar 2011 01:12:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59A2E37D-7CC7-408F-BF73-DBD4011A2066@gmail.com> References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> <20110315183111.GB2542@tuxdriver.com> <29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com> <20110315205146.GF2542@tuxdriver.com> <219C7840-ED79-49EA-929D-96C5A6200401@gmail.com> <20110315151946.31e86b46@nehalam> <1300228592.2087.2191.camel@tardy> <1300229578.2565.29.camel@edumazet-laptop> To: Eric Dumazet X-Mailer: Apple Mail (2.1082) Cc: Stephen Hemminger , 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 23:12:27 -0000 On 16 Mar, 2011, at 12:52 am, Eric Dumazet wrote: >> Back and forth synchronization between driver and device is >> doubleplusungood. Being able to remove a packet on the tx queue = already >> made known to the NIC sounds like it could become a rathole. If you = are >> lucky, you *might* have a "valid/invalid" bit in a packet descriptor >> that the driver could hope to set before the NIC had pulled-in a copy >> across the I/O bus. >=20 > There are two different use cases : >=20 > 1) Wired devices, where we want to push more 10+ Gbps, so we can = assume > a posted skb is transmitted immediately. Even a basic qdisc can be a > performance bottleneck. Set TX ring size to 256 or 1024+ buffers to > avoid taking too many interrupts. >=20 > 2) wireless, were typical bandwidth is small enough we can afford a > qdisc with a trafic shaper, good flow classification, whatever limit = on > "maximum waiting time in qdisc queue or drop it" and a very small = queue > on hardware ? >=20 > In both cases, we dont need to "cancel" a packet post to NIC hardware, > or we need special hardware support (some NICS already provide = hardware > TX completion times) Right, it is of course the wireless situation that I'm talking about. = And I am being a bit provocative about it. Ultimately, we need to be able to back off the transmit rate so hard = that the transmit buffer is *empty* half of the time, in the relatively = unusual cases where congestion collapse in the airspace has already = occurred. If every node has a packet to transmit, they will carry on = trying to get it on the air, and with the noise level already high and = the data rate already low, there is no way to recover the network until = some radios actually go silent for a while. The congestion-collapse problem is, I think, not easy to replicate at = home. It commonly occurs at conferences with hundreds of nodes in the = room. > Do the CPUs in handhelds possess that much more "oomph" > than "regular" systems did when 100BT or 1GbE first appeared? Typical handhelds now have anything from a 600MHz ARM11 (iPhone 3G) up = to dual-core 1GHz+ Cortex-A9s (iPad2, Galaxy Tab). The latter are = roughly equivalent to decent netbook/nettop hardware. There is = typically 512MB RAM in total. - Jonathan