I do also keep hoping for fq_codel or cake in miktrotik. However, it’s not an “or” choice so much, but an informed one.
Wifi: fq_codel for 3 wifi chipsets (mt76, ath9k, and ath10k) have existed now for a couple years ( https://lwn.net/Articles/705884/ ) however a key feature for the ath10k (and hopefully a few other chipsets we know of) (“airtime queue limits”) only just landed in mainline after baking in google’s wifi and chromebooks for a few years ( http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf ). This implementation lives in the mac80211 layer of the kernel,
and is not a qdisc, per se. It was our hope that the techniques we created and documented for this implementation would make it into vastly more wifi, 5g, and ethernet over powerline designs.
elsewhere:
fq_codel is lightweight and runs well at “line rate” on ethernet, wifi, - pretty much everything - , and there are few manufacturers that have offloaded it into the ethernet or wifi firmware itself at this point. fq_codel (rfc8290) is pretty much the default on most linuxes now, and also is on all of apples products. Some form of restricting the buffering the lowest level firmware (as per linux’s BQL or now, AQL) is also needed, and more than a few manufacturers and users have turned fq_codel on with hundreds of ms of buffering still stuck in the driver itself, expecting a better result. BQL is bog-standard in linux now, supporting - I’ve lost track - 50+? ethernet drivers - but not necessarily the ones mikrotik uses. Adding BQL to an ethernet driver is about 6 lines of code…
as for fq_pie, pie, codel, etc. In general we don’t recommend codel be run standalone. If you want to construct a sfq + codel thing, ok… but seriously, use fq_codel even with that.
I’m not a one trick pony - I’d like there to be a low latency high speed and bufferbloat-free internet for everyone - I’ve long supported development of pie, also. It is arguably (so long as ecn is disabled) a better single queue AQM than codel is. pie is lighter weight than fq_codel is, also, but doesn’t achieve anywhere near the same queue depth (16ms) that codel can (5ms). Pie keeps improving, with lots of new stuff landing in more recent kernels, including fq_pie, which just landed in linux 5.5. Some manufacturers (cough, cablemodems) have found it difficult to implement fq_codel in their devices, and hopefully fq_pie will prove a viable alternative. I’d really like some independent benchmarking of fq_pie vs cake and fq_codel, not just at line rate but in shaped modes. Cake in particular has docsis framing support, which the cable industry has thus far tried to ignore…
as for cake… well, after 5 years of user driven development, it was mainlined into linux 4.19, and the out of tree build for it goes back as far as 3.10. By default cake is about 2.5x more cpu intensive than fq_codel is, but it does a lot more - host + flow fairness, even through nat, ack-filtering, a better codel-like algorithm, etc. I like to think it’s currently the gold standard for sqm-software shaping, but again, independent benchmarks would be just great. cake is also our research vehicle for even more improvements in sqm designs. Try it at line rate as a shaper if you can spare the cpu, but be prepared to fall back to a simpler htb + fq_codel shaper if you can’t. Cake’s biggest objective was to be easy to configure, and only takes one line of tc code to enable on egress, 3 on ingress, unlike the sqm-scripts or more complicated things… and some more details can be had at the paper, here: https://arxiv.org/pdf/1804.07617.pdf
I think all these algorithms would be of value to mikrotik’s customer base and the bufferbloat.net folk and mailing lists are always willing to help. Let me leave you with a laugh though, in my recent talk at linux.conf.au I used people, as packets, to try and explain tcp’s behaviors better and the value of these algorthms.
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/
somewhere on these threads fq_codel_fast was mentioned… that’s an experimental version, with experimental “SCE” ( https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 )support, and I would not be in favor of mikrotik shipping that. There is a competing standards attempt, called L4S, that works differently, and I really don’t know where that’s going to go at this point. fq_codel_fast without that feature does benchmark out at about 5% faster than fq_codel presently does, but that’s pretty trivial in the scheme of things.
In summary - ship fq_codel for wifi, make sure you have BQL and AQL support underneath, ship fq_codel and cake, and feel free to play with fq_pie and pie. I look forward verymuch to playing with mikrotik’s implementations one day soon.
.