We have quite a few mikrotik users in the LibreQos chat server, and a burgeoning WISP community sharing insights and code. We recently switched to “zulip” chat which is highly interactive and a great deal of fun to use. It’s here: https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/
I am having a great deal of trouble understanding the direction of mikrotik presently - I would like to see cake or fq_codel + bql become a default for egress, and it made simpler to leverage cake’s bandwidth parameter without queue trees to do both ingress and egress. And that said, well, most of us have been abandoning inbound shaping entirely in favor of a LibreQos box there, and just using cake alone on egress, due to issues with “slow start”. So I kind of hope someone from mikrotik can enlighten me (either here or there), and perhaps with some better interactivity from this chat server, we can get through some more basic interop issues that keep cropping up. Is the dscp bug fixed? Etc.
I am using LibreQos but have an issue. One core goes to 100% and others stays below 5% when doing speed test. A thread named cpumap use the most CPU resource. Load can be scaled very well with RPS enable but Queues became very odd and Queue length is zero. It is due to the xdp-cpumap-tc used by LibreQos not compatible with RPS.
@arm920t Please feel welcome to join us on our Chat Server (link in top post in this thread). It sounds like you have a network.json with every AP under one node. Each top-level node corresponds to an HTB, which is tied to a single CPU core. To spread out the load, you need to change your network.json to have multiple top-level nodes so that each can use a different CPU core. Also RPS should not be used with LibreQoS, like you said it uses cpumap_redirect to achieve that. If you try to use RPS it will break LibreQoS.
Thank you for your reply. I think that’s the limitation of LibreQos right now. My network has only one subnet, so I can’t have multiple top-level nodes in network.json. Even if there are multiple nodes, a NAS consumes a lot of bandwidth when downloading, and this bandwidth belongs to one of the nodes. Therefore, the load cannot be extended to other cores. I did test a flat network topology, but the results were the same.
By the way, ROS scaled the load very well even with a single node. But Mikrotik doesn’t give an official configuration example. They just let the user “guess” whether it works. Someone tested Cake in a simple queue with internal Shaper and reported that it worked fine, but one day Mikrotik told us that we could only use Cake with bandwidth Settings in the interface queue. Interestingly, virtual interfaces like PPPoe client or bridge cannot attach any queue type directly. This makes cake shapers useless in most cases. Even Openwrt can attach Cake Queue to a virtual interface but ROS can’t. It’s confusing to me.
@arm920t You can have multiple top-level nodes, they don’t have to be tied to a single subnet. Make sure to individually define every customer, not to use entries like ‘100.64.0.0/24’ in ShapedDevices.csv - that is not how shaping is designed to work with LibreQoS. LibreQoS intends there to be a unique entry in ShapedDevices.csv for every customer. LibreQoS can do 10Gbps per core for loads of 50+ Gbps on high-end servers, so the single core problem you are facing is not a limitation of LibreQoS, but it could definitely be a configuration issue or insufficient RX/TX queues on the network interface card. Again, feel welcome to join the chat (https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/) and we can help with this.