From: Jonathan Morton <chromatix99@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?
Date: Wed, 16 Mar 2011 01:12:20 +0200 [thread overview]
Message-ID: <59A2E37D-7CC7-408F-BF73-DBD4011A2066@gmail.com> (raw)
In-Reply-To: <1300229578.2565.29.camel@edumazet-laptop>
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.
>
> There are two different use cases :
>
> 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.
>
> 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 ?
>
> 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
next prev parent reply other threads:[~2011-03-15 23:12 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 10:36 Jim Gettys
2011-03-15 14:40 ` Jim Gettys
2011-03-15 16:47 ` Jonathan Morton
2011-03-15 17:59 ` Don Marti
2011-03-15 18:14 ` Rick Jones
2011-03-15 18:31 ` John W. Linville
2011-03-15 19:40 ` Jonathan Morton
2011-03-15 19:59 ` Rick Jones
2011-03-15 20:51 ` John W. Linville
2011-03-15 21:31 ` Rick Jones
2011-03-16 0:32 ` John W. Linville
2011-03-16 1:02 ` Rick Jones
2011-03-15 22:01 ` Jonathan Morton
2011-03-15 22:19 ` Stephen Hemminger
2011-03-15 22:26 ` Jonathan Morton
2011-03-15 22:36 ` Rick Jones
2011-03-15 22:40 ` Jonathan Morton
2011-03-15 22:42 ` Stephen Hemminger
2011-03-15 22:52 ` Eric Dumazet
2011-03-15 23:02 ` Rick Jones
2011-03-15 23:12 ` Jonathan Morton [this message]
2011-03-15 23:25 ` Rick Jones
2011-03-15 23:33 ` Jonathan Morton
2011-03-15 23:46 ` Dave Täht
2011-03-16 0:49 ` Jonathan Morton
2011-03-16 1:02 ` Dave Täht
2011-03-16 1:28 ` Jonathan Morton
2011-03-16 1:59 ` Dave Täht
2011-03-16 2:23 ` Jonathan Morton
2011-03-16 22:22 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-16 23:38 ` richard
2011-03-16 23:50 ` Rick Jones
2011-03-17 12:05 ` Fred Baker
2011-03-17 12:18 ` Fred Baker
2011-03-17 17:27 ` Dave Täht
2011-03-18 18:30 ` Richard Scheffenegger
2011-03-18 18:49 ` Fred Baker
2011-03-20 11:40 ` Jonathan Morton
2011-03-20 22:18 ` david
2011-03-20 22:45 ` Jonathan Morton
2011-03-20 22:50 ` Dave Täht
2011-03-20 22:55 ` grenville armitage
2011-03-20 23:04 ` Dave Täht
2011-03-20 23:14 ` Jonathan Morton
2011-03-20 23:19 ` Dave Täht
2011-03-20 23:23 ` Dave Täht
2011-03-20 22:58 ` Jonathan Morton
2011-03-21 1:28 ` david
2011-03-21 1:56 ` Wesley Eddy
2011-03-18 18:27 ` [Bloat] Random idea in reaction to all the discussion ofTCPflavours " Richard Scheffenegger
2011-03-16 22:07 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-17 0:10 ` Jonathan Morton
2011-03-16 0:47 ` [Bloat] Random idea in reaction to all the discussion of TCP flavours " John W. Linville
2011-03-16 20:07 ` Jim Gettys
2011-03-17 2:26 ` Jonathan Morton
2011-03-17 18:22 ` Rick Jones
2011-03-17 21:50 ` Jonathan Morton
2011-03-17 22:20 ` Rick Jones
2011-03-17 22:56 ` Jonathan Morton
2011-03-18 1:36 ` Justin McCann
2011-03-18 5:51 ` Eric Dumazet
2011-03-15 16:34 ` Jonathan Morton
2011-03-15 18:13 ` Stephen Hemminger
2011-03-16 5:41 ` Fred Baker
2011-03-16 6:26 ` Jonathan Morton
2011-03-16 8:55 ` [Bloat] Random idea in reaction to all the discussion of TCPflavours " Richard Scheffenegger
2011-03-16 9:04 ` [Bloat] Random idea in reaction to all the discussion of TCP flavours " BeckW
2011-03-16 22:48 ` Fred Baker
2011-03-16 23:23 ` Jonathan Morton
2011-03-17 8:34 ` BeckW
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59A2E37D-7CC7-408F-BF73-DBD4011A2066@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=eric.dumazet@gmail.com \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox