Dave Täht writes the following in the CeroWrt-Devel mailing list:
This was the first time I've had a chance to try to actually deploy
cero as the main router in a production environment (esr's) in quite
some time. Enough problems cropped up for me to recommend against
using it as a primary router at this point, although I am writing
this email through it.
I did get some good data on how FIOS works (short summary: it's hard
to stress out FIOS)
You can download from http://huchra.bufferbloat.net/~cero1/3.3/3.3-rc5-1/
As noted in the Wiki and Activity pages, there has been a lot of recent work on CeroWrt. This has led to a usable firmware build that significantly improves performance with various new AQMs on a home router.
The bql-40 release incorporates Linux kernel 3.3-rc3, bind 9.9rc2, defaults to installing the snmpd, fprobe, and avahi packages and has a somewhat improved AQM. This build is for the bold - use it on your secondary router. If Linux 3.3 works out we will start a new, more serious development cycle around it.
Read the [[BQL_series_release_notes|Release Notes]] for details.
The recent bql-31 build is available for the bold. This build incorporates work from the Linux 3.3 kernel as well as a number of known queue disciplines (qdisc) that dramatically relieve bufferbloat. We believe the DNS/bind and IPv6 code are also working well. The build may have bugs and may not perform perfectly, but it is certainly better than the stock firmware or other builds. We'd like to get it in the hands of people who're willing to report problems (or successes!)
The [[Wiki]] page has information about downloading, installing, and configuring the build.
The "Ocean City" build is as done as it's going to get. It is stable, but its goals were way too broad to implement in a reasonable time period. As of mid-December 2011, we have declared victory, and chosen to focus on the essential experiments to decrease bufferbloat. This puts on hold all the rc7, rc8, etc. builds previously listed in the Roadmap.
If people have heard of bufferbloat at all, it is usually just an abstraction despite having personal experience with it. Bufferbloat can occur in your operating system, your home router, your broadband gear, wireless, and almost anywhere in the Internet. They still think that if they experience poor Internet speed means they must need more bandwidth, and take vast speed variation for granted. Sometimes, adding bandwidth can actually hurt rather than help. Most people have no idea what they can do about bufferbloat.
So I’ve been working to put together several demos to help make bufferbloat concrete, and demonstrate at least partial mitigation. The mitigation shown may or may not work in your home router, and you need to be able to set both upload and download bandwidth.Two of four cases we commonly all suffer from at home are:
- Broadband bufferbloat (upstream)
- Home router bufferbloat (downstream)
Rather than attempt to show worst case bufferbloat which can easily induce complete failure, I decided to demonstrate these two cases of “typical” bufferbloat as shown by the ICSI data. As the bufferbloat varies widely as the ICSI data shows, your mileage will also vary widely.
There are two versions of the video:
- A short bufferbloat video, of slightly over 8 minutes, which includes both demonstrations, but elides most of the explanation. It’s intent is to get people “hooked” so they will want to know more.
- The longer version of the video clocks in at 21 minutes, includes both demonstrations, but gives a simplified explanation of bufferbloat’s cause, to encourage people to dig yet further.
Bloat: CACM Bufferbloat paper and case study is out. (108 comments)
CACM Bufferbloat paper is out. It's the same as the ACM Queue version, but killing trees... You too can read it in the comfort of your bathroom.
The case study conversation led by Vint Cerf is in the February issue, but that hasn't arrived in at least my mailbox yet.
FWIW: they should be fixing the access on the ACM digital library site to be public, once I deal with copyright stuff. But the ACM queue links are just fine for now.
Two articles have just been posted on the ACM Queue Web site as part of a Bufferbloat case study. These are an article by Jim Gettys and Kathleen Nichols, and Vint Cerf interviewing Van Jacobson, Jim Gettys, and Nick Weaver.
These will hit your snail mailbox in the January 2012 CACM (Communications of the ACM).The publications are:
You can find it online here.
It is copyright IEEE; it is used with their permission on this web site.
Bloat: Server maintenence today - Monday, April 25 (1 comment)
Bufferbloat.net has grown by leaps and bounds and we are in need of replacing the email server and migrating a few services over to our new, beefier box, "huchra".
Email, web, and build services will be disrupted periodically.
I'd intended to write up summaries of bufferbloat related activity once a month, but am running a bit behind. Both JG and I have been travelling heavily.
There's been a lot going on under the covers!
Probably the biggest news is that we are working with Georgia Tech on their bismark project. They are out to diagnoise the Internet and we are out to fix it. The two goals seemed compatible. In particular: we are trying to de-"heisenbug" the test routers so they can accurately test the upstream services.
We've also taken the wraps off the "uberwrt" project2, which is an attempt to get the debloating work TESTED in realistic situations at the edge and also into openwrt. (Some work from this also flows into bismark)
I was going to write formal joint press releases on these but have been too busy traveling, talking and hacking. (if anyone wants to step up to handle PR?)
Although traffic on the bloat mailing list has been slow of late, the bismark-devel list has been hopping. Feel free to join bismark/uberwrt projects and/or the mailing list3, especially if you are interested in embedded hardware.
Moving on to other topics...
Based on the early difficulties in getting debloat-testing to be a useful base for the eBDP and A* algorithms, we started looking around for ONE driver to work with and have settled on ath9k hardware (for now) as a base for routers and wireless cards.  We need to do a little testing of the laptop cards, but things are looking good. the WNDR3700v2 is AWESOME, actually. 16MB of flash. LUXURY.
Dan Siemon's pfifo_fast fix for ECN has been backported into 2.6.37.X for openwrt's git head as of Saturday. It's also now part of 2.6.39 and 2.6.38 stable.
SFB is in mainline Linux 2.6.39-RCX and woefully undertested in its current incarnation.
Felix Feitkeu has some patches more fully instrumenting the ath9k driver (when mildly more complete, these should get slammed into debloat-testing as well) 
Dan Siemon has improved both his TC shaper test scripts and ping-exp 
Media: There were a couple articles on bufferbloat that went by this month, I think they were all covered on this list...
There are 236 members of the bloat list now.
We are moving a ton of work to a new build server and also moving the lists machine to that. Regrettably as I write, "huchra" is down due to finger-foo. It should be back up again Monday.
Multiple other servers in other locations are in the queue. I hope to get that sorted out with isc while I am in California.
JG will be in California April 25-30. I will also be in California April 25-30 (in at least one of the same places as JG), and am available for additional talks/coding/consulting/etc along the western seaboard in early May if anyone wants me and can cover my expenses. (Sort of scheduled: Byte and Atheros U) I'll also be visiting Seattle at some point in May, too.
Travel last month:
I spent a week in florida gathering strength for my world tour. Then I spent a week with Georgia Tech helping get their Bismark project off the ground and hammering out workflow issues.
I was tickled pink when I gave an introductory talk on bufferbloat to a class there, only to discover when Q&A rolled around that everyone participating was already up to speed on bufferbloat and queueing disciplines, and peppered me with questions on SFB, RED, eBDP and other algorithms we are playing with. 3 months ago I would have been met with blank looks, now it's a struggle to keep up!
I then spent a week with esr getting one of the first near-complete builds of the wndr3700 working well, working on gpsd (wanted accurate time on openwrt) and rsnapshot and split dns and a host of semi-bufferbloat.net-and-uberwrt issues... And we also got a revised version of the intro to bufferbloat document up on the wiki .
I'm very happy to see thyrsus.com go ipv6 enabled.
The bufferbloat wiki is still in dire need of love, see the Todo list for more details  -
And that's all the news I can remember this late Sunday evening. It's my hope that SFB will make it into bismark/uberwrt this week so we can test SFB a little more while it is still a RC in 2.6.39. I'd VERY MUCH like to make sure SFB works when it is released to millions of users worldwide. That will be in 4 weeks or so... I'm feeling a little schedule pressure here... See dan siemon's scripts... 
 http://www.bufferbloat.net/projects/bismark/wiki Georgia Tech's project
 https://lists.bufferbloat.net/listinfo/ (bismark, bismark-devel)
 http://git.coverfire.com/ PLEASE PLAY WITH TC, SFB, and PING-EXP!!!!
The bandwidth you save may be your own.
 http://battlemesh.org/ has summaries and videos from the battlemesh
 The original of the bufferbloat introductory piece was extensively discussed on this mailing list. This versions incorporates most of those changes. If you don't like this version... It's a wiki document now! Please feel free to fix, extend, and add links! http://www.bufferbloat.net/projects/bloat/wiki/Introduction
 LOTS of writing left http://www.bufferbloat.net/projects/bloat/wiki/ToDo
 After evaluating multiple routers, http://www.bufferbloat.net/projects/uberwrt/wiki/Hardware_evaluation
seemed like the best choice
Bloat-announce mailing list
Also available in: Atom