Bug#890343: fq_codel as a default
cake and its default parameters is designed to run just fine as a
default qdisc at whatevr the line rate is in linux. I do it all the
time. I find the per host/per flow fq useful, the sane diffserv
markings helpful, the gso splitting best for low latency apps like
videoconferencing, and the stats often enlightening, and I do wish
more folk ran it by default.
however, cake is far more cpu intensive (and slightly more memory
intensive) than fq_codel is and given the wide range of hardware
debian runs on, I cannot support
the idea of it being the default qdisc. I could put up a benchmark or
three as to the difference in cpu on the raspberry pi 3 and 4 to
illustrate this point.
Certainly pfifo_fast must die! Up until last week I thought fq_codel
WAS the default in debian (in addition to *wrt,ubuntu/fedora/rhel8,
arch and so many others) but hd been fooled by linode supplying their
own kernel for everything.
I'd of course love to see it built by default (along with sch_fq and
fq_codel), and more people just reach for the lovely one liner of
tc qdisc add eth0 root cake bandwidth XXX
whenever they need to shape something, AND use it at line rate
(without the bandwidth param) where they can afford it... but I think
the decision tree for a linux default at this point would be
fq_codel (for generic workloads)
sch fq (for tcp serving workloads)
cake (if you can afford it)
bfifo
pfifo_fast
I had a long and (apology, all, oft testy!) debate on the benefits of
fq_codel vs pfifo_fast vs sch fq over here, with the most relevant
comment here:
https://github.com/systemd/systemd/issues/9725#issuecomment-413369212
--
Make Music, Not War
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
Reply to: