I try to stress that the cake effort had a large team, and was exhaustively driven by demand of thousands of users using sqm. I’m just one of the most visible.
I would very much like the new LE codepoint ( https://datatracker.ietf.org/doc/html/rfc8622 ) become widely adopted. CS1 proved too problematic, and a “background” class is the only diffserv codepoint I actually agree with, with the caveat that the rfc specifies it should be starvable, and I prefer an interpretation of “at least 5%”, because no end user their right mind would want traffic that potentially never completes.
Its a 1 character patch to each of cake’s lookup tables. We submitted it to the kernel as soon as it was finalized.
PS We tried very hard to match wifi dscp behavior in the 4 tier cake model, and I have seen cell-over-wifi actually use dscps with good results (0 loss, 0 delay), so my original position against any dscp usage at all (favoring per-host/per flow fq-codel only), at least for voice, has softened. Where I stand for videoconferencing… well… Its too early to tell. I personally ended up switching to the 4 tier model and remarking zoom traffic to suit…
… and have been working with galene.org to create the lowest latency videoconferencing server as yet seen, using the gcc loss and delay based congestion controller. zoom goes WAY overboard on adding delay IMHO.
failing that it’s my hope more here actually test. slam cake on an interface, try the rrul tests in flent, or drive it hard with a test too of choice and inspect the packet capture.
are they exposing the rtt, ack-filter, nat or other options?
Mikrotik has some decent documentation they put up for the queues they added in v7 and their associated options, including CAKE: Queues - RouterOS - MikroTik Documentation
Here’s a screenshot of what’s offered when initially creating a CAKE queue as well. So it looks like they are exposing those options.
EDIT: since I am using a Cake queue as ingress in real life but can’t specify it (I guess it defaults to egress). Will the internal Cake algorithm be optimal? I noticed that I must lower my bandwidth quite a bit for Cake to not try to go over my connection speed, unlike for uploads. I have a Fiber 100/50 connection.
i have been using the beta6 for some time at a lab with clients connected to it, I noticed a new thing in the queues, if there is a child queue, then the parent queue will only receive packets that will pass by the CHILD queue TOO, or else it won’t that means you can specify same target queues with a specific order, yet the higher queue will only receive what its children receive even if it is high in order!
that made it possible for me to specific queues for hotspot and PPPOE users, and the parent queue will only receive data for the client’s queues.
in this RC4 (may be 3 too ) I can not do the same thing although it was a cool thing! Any idea if this thing can be activated and deactivated!
As soon as queue has at least one child it becomes a inner queue, all queues without children - leaf queues. > Leaf queues make actual traffic consumption, Inner queues are responsible only for traffic distribution> .
I just noticed that log files aren’t preserved upon reboots on my hapac2. I’m using the dafault disk action. I also tried to move the file to flash/log, without luck.
No /log.1.txt is created, and log.0.txt only contains messages since the device has restarted.
It doesn’t matter if the router is restarted normally or by watchdog.
On other devices (running v6) the content is moved from log.0.txt to log.1.txt, like it is documented in the wiki, that’s why I post this here.
I do have the suspicion that the mlag peer port is causing issues with Spanning-Tree… looks like the peer port is creating a loop when using multiple VLANs.
I have two uplink ports per switch connecting to another MLAG Switch… as soon as I bring up the MLAG Port one of the switches is no longer reachable - and traffic on the uplink ports is massive.
I did open a support ticket and did send them the logs…
Setting up routing filters is still an awful, miserable, pointlessly tedious experience. Why was this designed this way? Are there plans to make it less of a complete pain? Old filters worked great. New filters are trash, essentially, by comparison. Will also require lots of training time to bring others up to speed for seemingly no reason or benefit.
It wouldn’t be so bad but the documentation is basically “ok now go have fun” instead of actually helpful information.
Is anyone else having issues where you need to separately define network and interface under interface template? If I just have one or the other I often won’t get full adjacency, though when I have both it will sometimes just show invalid for no reason. Reboot the device and all is valid again with no configuration changes. Often have to toggle the ospf instance as well after a reboot in order for routes to change hands even with full adjacency.
I’m sure there must be a better way to do things but with how things are currently set up and not documented in any kind of intelligent way it’s rather difficult to figure out what the best practice should be. Since it’s a 5009, I can’t exactly just put it on a version of RouterOS that actually works either.
