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

On Fri, Mar 27, 2015 at 5:14 AM, Philipp Kern <pkern@ubuntu.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@nuc-client:~$ cat /etc/sysctl.d/10-bufferbloat.conf
> net.core.default_qdisc=fq_codel

Changing it with the sysctl is a flawed approach, though. If anything
initializes the network interface early (case in point: dropbear
decryption during initrd), then that interface will still adopt
pfifo_fast as its qdisc.

Merely getting to where a big distro would turn it on in any way has been the PITA.

Openwrt did it long ago and everyone downstream from them also. Arch is taking systemd defaults to fq_codel, so that has been widely used with no negative feedback I know of. Plenty of other places...

I think it would be saner to make the case on the bug itself rather than on this thread.

Maybe setting the kernel parameter would be the better option? ;-)

I am under the impression if you down and up the interface you get the desired result. Will fiddle.

But if you are willing to go the full monty... the out of tree patch to make it be the default at boot is here for several linux versions.

http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/generic/patches-4.0/662-use_fq_codel_by_default.patch;h=e7b781be9b38a92926f892c785070f9bc5f25a68;hb=HEAD

I guess this could become a kbuild option. Arguably sch_fq is now superior in many cases (native host, serving lots of tcp flows, now serving over 25% of the world's internet traffic), but it seems not suitably generic for vm base machines, routers, or lots of udp traffic. A (well protected) web-serving deployment would probably choose sch_fq at this point.

My hope was merely that it could be tried as a default during a development cycle to see if anything broke (unlikely at this point), and to see users observed the same improvements with various network subsystems (100mbit, 10mbit, wifi, usbnet, etc) that we do. (ideally, it just slots in and nobody notices. :) )

Kind regards
Philipp Kern

--

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

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb