I was very very happy with all your help testing and exploring fq_codel and cake on this enormous thread: viewtopic.php?p=937633
(which I don't want to add to!) and equally happy that it seems to have stabilized in current mikrotik releases. But I had questions unanswered then, that perhaps y'all, with some deployment under your belts, can answer.
my update on bufferbloat
Since that thread, ookla released a version of their speedtest apps that test for responsiveness under load: https://www.ookla.com/articles/introduc ... ed-latency
The hysterical thing about this is I've seen test after test published since (notably on starlink) where the reviewer completely missed the latency figures it now reports for a simultaneous up or download. Do any of y'all have before/after cake data from speedtest you can share?
Also since that thread I went heads down on fixing up some bugs in the fq_codel for wifi implementation in openwrt 22.03, and the fixes are now in 22.03-rc6. I hope that mikrotik has followed along with that stuff in their wifi stack(?)
I helped a fairly large ISP recently analyze a mikrotik + libreqos implementation. They started with libreqos, which made such an enormous difference that they immediately started deploying cake directly on the mikrotik cpe they had. The sudden silence of speed related calls from tech support was palpable. I wasn't able to get good stats from the middlebox before they started over to mikrotik native but truly amazing to me were:
* The sheer number of packet drops - nearly 1% at the lowest "speed" tier, led to very perceptible improvements in speed.
* a goodly number of their subscribers actually were using ecn for congestion control, effectively or not I can't tell.
* a significant of data was actually marked with a non-default dscp marking, landing in the cake voice queue. I generally see zero drops and latency in this queue so it seems like a win. I surmise this traffic is lte over wifi.
Another thing I found (using flent) was that a given "2 gbit" fiber peering arrangement actually peaked at 1.2gbit (line card limit??), and had over 250ms of buffering in it if you hit it with 16 flows, which was invisible with only a single flow. Fixed with cake. I would encourage y'all to stress test and cake your peers now that you can slap cake on your bigger links. (and I really wanted data to how high it could scale on the bigger mikrotik routers)
Open Questions
* Anyone have results on replacing their default fifos and/or sfq with fq_codel?
* Has correct documentation for how to configure cake landed anywhere on the mikrotik site?
* Is there any way to get mark and drop stats out of mikrotik after applying these algos? snmp?
... really, this is the biggest thing that makes me nuts, is not having that kind of data. I'm a data junky.
* does cake work over mpls?
Open Feature requests
* I'd dearly like mikrotik to provide a way to tune down the tx ring on older mikrotik wifi gear. It's easily 3x too big at mcs-12.
* It would be great if cake's bandwidth shaper could be used in both directions on the interface, rather than hfsc. For many users of this gear, that simplicity would make a big difference, and be lighter weight.
...
I'm going out for some grant money soon (or other funding) and if there's any features y'all want in libreqos/cake/fq_codel now is the time to ask...
@Larsa @BitHaulers @WeWiNet @gtj0 @DanielJB @mducharme @Amm0 @kevinb361 @jmszuch1 @blurrybird @ivicask
@eider @Tporlapt @WeWiNet @IPANetEngineer @jult @mke @skoenman @denisun @rooneybuk @kikikaka @ilium007 @Rfulton @felixka
@Trunkz @arm920t @Lodion @chechito @brotherdust @jbl42 @dalami @kaixinwang @syadnom @Techtress