Cake would be awesome in v7. I just did some testing with openwrt and it performed surprisingly well.
I can’t imagine why they wouldn’t include it in v7 since most of the hard work is already done and openly available…
Wow everyone dtaht is here, and what an amazing response!!!
If you don’t know now you know… https://github.com/dtaht
Please Tik admins read the above and reach out!
And Dave, thanks for so much for all your efforts.
Gentle nudge.
I need a new router, choice is 4011 or ER4, one has some features I need and the other has SQM. Please make my decision easier!
I have the same situation.
Another Vote for SQM
-1
I have never had good experience with SQM as implemented in openwrt or ubnt ER. Practically most of the time SQM does hurt performance of TCP connections significantly. Mostly it does is introduce packet loss, and a lot of it. Now, the traffic I deal with is idiotic - sub-second bursts in the order of 12-25mb, then 8-9 seconds idle and then such a burst again. The receiving and sending devices are also idiotic, closed source systems that insist on keeping receive window at 16kb.
What works best is a poor man tcp optimization (traffic is passed via the router proxies) thus making the idiotic small receive window size only a problem in the last segment. The proxy in mtk is severely limited so a better proxy or a real tcp optimization engine (and ability to do automatic optimization in certain cases based on firewall rules will be great) is needed much more than SQM. If you set your PCQ properly you don’t have problems. This is the setup that works best for me:
- use a queue tree for the interface outgoing traffic
- set a top PCQ to do all 4 criteria - dst-address, dst-port, src-address, src-port and mask at /32 for ipv4
- calculate bandwidth delay product for 5ms at data rate and set as pcq-limit (.e.g 25mbps the value is 15)
- calculate bandwidth delay product for 5ms at line rate and set as pcq-total-limit (e.g. 100mbps the value is 61) - the default of 2000 is way off
- set max-limit to your data rate or 95% of it, though usually data rate is enough
- use subqueues if needed but in this case the pcq-total-limit is calculated for the bandwidth of the outer queue data rate assumed as line rate for the inner, each inner subqueue needs its own pcq
- do this as close to the source of traffic as possible
Seconded. This would be a welcomed addition for many. Please consider it.
CAKE on DD-WRT worked much better than Mikrotik’s SFQ queue tree but it’s too unstable for home networking (wifi crashes, wan drops, etc), consider adding CAKE queue type instead of FQ-Codel since it provides the lowest fluctuations during heavy load, http://www.dslreports.com/speedtest/63079766 this is what I get with MK solution but the latency spikes up to 300ms while CAKE consistently mantained it under 130ms giving me A+ ratings.
Edit: this is my current config
ROS 7 is now running over Linux 5.6.3 kernel, so I guess it’s the time for real SQM like CAKE or fq-codel to be available in ROS
I’m planning to overhaul my home network by buying a TP-Link EAP-245 external AP and do SQM on my existing hAP AC2 router but there’s still no SQM support in ROS 7 
It’s a shame cause this little box has killer hardware for routing
It’s just Mikrotik not willing to implement modern queuing techniques on ROS, here’s an speedtest of my hAP AC2 running piece of CAKE on OpenWRT firmware it just got rid of bufferbloat in a few clicks
PD: I have 75/75mbps fiber but I limited it to 72000/72000kbps, tested over ethernet
Here’s my 100/50 Mbps:
What’s wrong with bufferbloat?
Congrats, your ISP is probably doing an excellent QoS job so bufferbloat is not a problem for you
Those are my results without SQM
Edit: I tested with hi res bufferbloat enabled, it makes more latency tests per run to give more accurate results.
Bufferbloat and Beyond Removing Performance Barriers in Real-World Networks
Author Toke Høiland-Jørgensen
Video: https://www.youtube.com/watch?v=09i48X2_ex0
Slides: https://blog.tohojo.dk/slides/bornhack2019-bufferbloat-beyond.pdf
Doctoral thesis: https://blog.tohojo.dk/media/bufferbloat-and-beyond.pdf
Since it seems Mikrotik will never implement this, I’ve been experimenting with the options we DO have … I found that setting a simple queue and capping UL/DL to 80% of rated bandwidth , and using PCQ yields very good results. It’s perceivably faster and more responsive in all my applications and games. I have a CCR1016 and perhaps having that many PCQ queues to use all my cores accounts for this improvement.
This should help you all: http://forum.mikrotik.com/t/using-routeros-to-qos-your-network-2020-edition/66683/1
With Cake I get rid of lag (dslreports A+ wired and A+/A over 5ghz) by limiting my 75mbps connection to 72mbps, Mikrotik queues requires me to sacrifice way more bandwidth (~10mbps) to get an A result on dslreports. I guess this is caused by the ancient SFQ qdisc being a round robbin algorithm and subsequently the SFQ based propietary PCQ.
I actually like Mikrotik micromanagement and categorization approach but the SFQ qdisc makes it a latency disaster, if we could just select fq_codel as queue type it would be a great improvement.
It did help.. there was tip in the thread to adjust the bucket size to 0.005 and that made a big difference in my network.
+1 for fq_codel or cake
++1
I have the feeling that a new beta is coming 