I have been trying to improve the bufferbloat and codel related information on various sites including bufferbloat.net's and wikipedia. In going through the fora here, I see a few issues and bits of information that are either obsolete or inaccurate. Since I'm a guest user I can't post links so I will refer to googling for references….
To address the 2 year+ backlog of what I just read here in one go:
0) Cable has tons of bufferbloat on ingress and egress. FIOS has it on ingress. DSL - generally running at lower speeds - seemingly often has some smarter queue management on it.
Some pictures of what a difference you can make on real edge networks on fios and cable are shown here:
google for "rrul rogues gallery"
These benchmarks are using the cerowrt branch of openwrt, but the scripts are very simple and can be used on anything.
1) codel and fq_codel were put in the compat-wireless trees about a year ago. So far as I know that has been backported as far back as linux 2.6.32. So if your build on a kernel older than 3.5 is using compat-wireless, you have the potential to turn this stuff on. (A newer version of tc is required). From what I read in these forums, many broadcom chips are still stuck at 2.6.22? Ugh.
2) codel is nice. fq_codel combines the best behaviors of sfq or drr PLUS red and continues to win tons of benchmarks. Doesn't mean that it's end-all, but qos systems using it on the gateway side have thus far been very impressive (see the ietf demo as one example off of here: google for "Bloat-videos")
3) fq_codel is on by default in all of openwrt, on all devices running latest kernels. This is somewhat premature for wireless, there is a great deal more work left to do there, but there is often a visible benefit. The biggest visible benefit is with combining it with a rate limiter (like htb or hfsc) in your classic 3 tier QoS system.
4) There has been a lot of talk here about dramatically reducing txqueuelens. This will help on some devices and hurt on others. In the absense of queue management, a dumb ethernet chip and driver can use txqueuelen, many wifi drivers can run with something very small as the device drivers are horribly overbuffered. The latest generation of ethernet chips are moving "smarts" into the chip and driver, which bypass txqueuelen entirely (and might not be so smart after all…) When in doubt, measure.
5) It is better, in the general case, to size the buffers dynamically based on the delay packets experience getting upstream. IMHO. Google for "traditional aqm is not enough".
Gargoyle is doing some interesting stuff with measuring incurred delays with a tool called ACC and modifying the hfsc + sfqred implementation to suit, as one set of ideas. Cisco is fiddling with "Pie". Some are combining forms of QFQ or WFQ with pie or codel in different ways.
6) The ietf is considering a new standardization effort around various forms of AQM. Whether or not a new working group is to be formed will be decided this week.
7) I'd like to know what tomato's been doing on these fronts, regardless.
— Dave Täht