Minutes from the Ubuntu Kernel Team meeting, 2015-03-24

Dave Taht dave.taht at gmail.com
Thu Mar 26 18:12:18 UTC 2015

On Thu, Mar 26, 2015 at 10:00 AM, Andy Whitcroft <apw at canonical.com> wrote:
> On Tue, Mar 24, 2015 at 10:54:37AM -0700, Dave Taht wrote:
>> I must confess I had hoped ubuntu would adopt fq_codel as the default
>> qdisc in this go-around. It is still not quite part of fedora´s
>> default either, but is now in arch, (and nearly everyone else
>> downstream from systemd), and has long been the default in openwrt,
>> and at this point, just requires a single sysctl to enable.
>> It certainly could use more widespread testing, perhaps in the next release?
>> d at nuc-client:~$ cat /etc/sysctl.d/10-bufferbloat.conf
>> net.core.default_qdisc=fq_codel
> Changing something so fundamental is always scarey.  I've filed a bug to
> review this[1] so we do not forget.

yes, it is. when the technology was first developed, and the first
(wonderful) benchmarks arrived, I then freely admitted to being
terrified of what else we would break if we deployed it widely. Here,
for example, about 44 seconds into the last bit of my dec 2012 talk in
modena[2]: https://www.youtube.com/watch?v=JFH5fGNzBJU - I talked to
my own terror.

Afterwards we travelled the world talking to experts, doing testbeds,
test deployments, and have by now got lots of research, benchmarking &
actual deployment data. There's nearly complete standardization
activities in the ietf aqm working group also. So... 3 years later, we
are pretty confident that it can indeed, be safely turned on by
default, and be of benefit in more circumstances than pfifo_fast is.

Thank you for filing the bug to track it. Would you like us to further
make the case for trying it on the bug itself?

Another path towards trying fq_codel on by default in ubuntu would be
to merely add a debloat.deb package, and also improve the sqm-scripts
to be .deb installable. Would that be a path forward?

And/or wait for more results from arch and fedora to come in.

A third path towards folk gaining confidence in the fq and codel
algorithms for general use would be by more people fixing their own
home and small business gateways with it -

I am of course a big fan of more folk making their cable, dsl and
fiber behave better on the gateway, particularly in places that have
3rd world bandwidth and first world bufferbloat. Improvements seen
there are pretty massive.

Cable: http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html
Fiber: http://zlkj.in/fiber-sqm
DSL: http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat

Presently we use ubuntu extensively throughout the bufferbloat.net
networks and testbeds, and we've been using the x86_64 version for
fiber and high speed cablemodem tests as low end gear openwrt supports
can't run htb fast enough.

Cable modem at 115mbit/12mbit before sqm-scripts + fq_codel [4]


after sqm-scripts + fq_codel


Note: I do not wish to be confusing (what I am advocating here is that
fq_codel also be turned on universally replacing pfifo_fast in your
distro, in addition to these specialized hyper-useful rate limited

Kamal has benchmarks at 100 and 10mbit, as best I recall.

> -apw
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1436945

[2] http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

[3] esp ethernet at 100mbit, 10mbit, and with pause frames, usbnet,
etc. Even on wifi it helps somewhat, but the make-wifi-fast project is
only just starting...

[4] since fq_codel is so stable now, we are moving towards developing
newer technologies for handling rate limiting better at higher rates
("cake"). Also in this dir are benchmarks of codel and pie by
themselves and a few other things under development,
all browsable via the netperf-wrapper tool.

Dave Täht
Let's make wifi fast, less jittery and reliable again!


More information about the kernel-team mailing list