| |||||||||||||
LCA: Vint Cerf on re-engineering the InternetLCA: Vint Cerf on re-engineering the InternetPosted Jan 25, 2011 10:40 UTC (Tue) by gdt (subscriber, #6284)In reply to: LCA: Vint Cerf on re-engineering the Internet by ebiederm Parent article: LCA: Vint Cerf on re-engineering the Internet
Yep, exactly. Re-reading my posting I wish I'd spent more time making clearer the distinction between (1) TCP buffers in end systems and (2) IP buffers on the egress interfaces of routers. The leaflet was about (1), Vint obviously thought from the context of the question that the leaflet was about (2).
(Log in to post comments)
LCA: Vint Cerf on re-engineering the Internet Posted Jan 26, 2011 1:25 UTC (Wed) by mtaht (✭ supporter ✭, #11087) [Link]
Not having seen the leaflet I don't know what, specifically, to address.
One core problem of bufferbloat is that devices and device drivers are currently doing too much *uncontrolled* buffering. The TCP/IP stack itself is fine, however, 1) once a packet lands on the txqueue, it can be shaped, but rarely is.
2) Far worse, in many cases, especially in wireless routers, once a packet gets off the txqueue it lands in the driver's queue, which can be quite large, and can incur huge delays in further IP traffic.
Once the device driver's buffers are filled, no amount of traffic shaping at a higher level will help. Death will not release you.
Here's a specific example:
Linux's default txqueuelen is 1000. Even after you cut that to something reasonable, it then hits the device driver's buffers. The driver I'm specifically hacking on (the ath9k, patches available here: https://github.com/dtaht/Cruft/raw/master/bloat/558-ath9k...
Assume your uplink is 3Mbit/sec, what's your maximum latency?
I'm not going to show the math here, it's too depressing. If you have an ath9k, try the above patch. there's one for the IWL going around. Many ethernet devices support ethtool...
The difference in overall network responsiveness with the crude ath9k patch above is amazing, and I've still got a long way to go with it.
This paper: http://www.cs.clemson.edu/~jmarty/papers/PID1154937.pdf
There's plenty of experimental data out there now too, and experiments you can easily perform on your own devices.
http://gettys.wordpress.com/2010/12/02/home-router-puzzle...
Every device driver I have looked at defaults to uncontrolled buffers far in excess of that figure, usually at around 256 buffers, even before you count txqueuelen.
The key adjective here for coping with bufferbloat is to reduce uncontrolled" buffering, starting with the device driver(s) and working up to various means of traffic shaping and providing adequate feedback to TCP/ip streams (packet drop/ECN etc) to keep the servo mechanism(s) working.
LCA: Vint Cerf on re-engineering the Internet Posted Jan 26, 2011 3:02 UTC (Wed) by jthill (guest, #56558) [Link] But isn't the uplink the advice is for a gigabit uplink, not 3Mb? If that's right, I make the uplink latency for a full ath9k queue well under 10ms - they should be able to run flat out. That or I borked the math.
LCA: Vint Cerf on re-engineering the Internet Posted Jan 26, 2011 4:11 UTC (Wed) by mtaht (✭ supporter ✭, #11087) [Link]
In the case of a wireless card in your laptop or a wireless link you can be running at speeds ranging from 300Mbit down to 1Mbit/sec, or less.
In the case of a home gateway, my comcast's business class service is running at about 3Mbit/sec on the uplink.
Huge dark (unmanaged) buffers in the device affect latency really badly - not just for TCP/ip, but for stuff that would ordinary jump to the head of the queue - udp, dns, voip, gaming, NTP... ... and in some cases are so big as to break TCP/ip almost entirely.
We've been sizing device buffers as if it was all on gigE backbone networks. Nor have we been using reasonable AQM. I urge you to try the experiments mentioned earlier.
LCA: Vint Cerf on re-engineering the Internet Posted Jan 28, 2011 6:45 UTC (Fri) by The_Barbarian (subscriber, #48152) [Link]
Why, I happen to have an ath9k. I'll give this a whirl at some point. Thanks!
LCA: Vint Cerf on re-engineering the Internet Posted Jan 29, 2011 5:12 UTC (Sat) by mtaht (✭ supporter ✭, #11087) [Link]
If you are doing openwrt development on the ath9k I have builds with that patch for the wndr5700 and ubiquity. I have never been more happy to see packet loss in my life.
LCA: Vint Cerf on re-engineering the Internet Posted Feb 11, 2011 16:43 UTC (Fri) by mcgrof (guest, #25917) [Link]
Looking forward to the final upstream patch and respective commit log entry :)
LCA: Vint Cerf on re-engineering the Internet Posted Feb 11, 2011 17:08 UTC (Fri) by mcgrof (guest, #25917) [Link]
On second though, the bandwidth for 802.11 will change dynamically depending on the topology of the 802.11 environment, if you're an AP on the STAs connected and their own 802.11 counterpart. So I wonder if the internal buffers are best adjusted influenced by rate control who will have a better idea of the average bandwidth to peers through one 802.11 interface.
LCA: Vint Cerf on re-engineering the Internet Posted Jan 26, 2011 21:15 UTC (Wed) by mcoleman (guest, #70990) [Link]
If you're Vint Cerf, you might be thinking that most conference attendees bring their own routers with them (perhaps several). ;-)
|
|||||||||||||