Hi, I have a small home lab where I use a wireless CPE as an uplink—currently running an AC3 as CPE and an AX3. I decided to switch to the hAP AX S to test the capabilities of the new drivers.
My configuration is simple: I am bridging all ports and the 5GHz Wi-Fi with WPA3 enabled. The physical link signal is -58 dBm, with modulation around 950 Mbit/s in both directions.
Sadly, I suspect there might be an issue with the bridge implementation in the hAP AX S drivers. While my private DUDE server can perform a 600 Mbit/s download BTest without breaking a sweat, a regular speedtest on a PC connected to ETH1 only reaches about 150–200 Mbit/s (and I've tested this on multiple PCs). When the PC is connected to the hw switched ports (ETH2–5), the speedtest reaches around 250–300 Mbit/s. Also, some websites behave strangely. Since the BTest via the DUDE works fine, I assume the issue isn't with the physical link or the wireless chip itself.
For comparison, my old AC3 with the same configuration achieves a real-world speed of 450/450 Mbit/s, even with a modulation of only around 600 Mbit/s.
I remembered some versions way back that the default script used to set fq-codel-ethernet-default queue to the ethernet interfaces. Now this doesn’t seem to be the case when looking into /system default-configuration print in 7.21.3, and I don’t know when this changed.
No one from MikroTik has ever explained whether the FQCoDel interface queue offers any benefit over using only the hardware queue. I have not been able to measure any improvement
On my Linux laptop running 6.19.2-1-MANJAROthe queues are setup as such:
# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev enp0s31f6 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc noqueue 0: dev wlp0s20f3 root refcnt 2
Atm I couldn’t find Dave Taht’s @dtaht, rest his good soul, treatment on the subject regarding bufferbloat that made many distro kernels switch ethernet queues to defaultfq_codel.
On a router, there is a switch chip. I do not see the benefit of using a software queue on hardware-offloaded switch ports. At least in my case, I could not measure any improvement, although maybe my tests were not appropriate for evaluating this.
That is why I said I would appreciate seeing some explanation or evidence from MikroTik about why they decided to change the default configuration on LTE devices. In general, I would not assume that MikroTik modifies the default configuration without a specific technical reason.
Since LTE modems are never run by switch chips, they are thus not HW-offloaded and hence your observation about software queues doesn't apply to LTE interfaces.
As already mentioned, @dtaht went into great extents explaining why certain queue types (fq_codel in particular) work better than others. And I would guess that devs at Mikrotik came to concluson that fq_codel (or some other software queue) actually fares better than (simple) hardware queues ... so why not using those by default on ports where software processing actually occurs?
It is fqcodel interface queues on Ethernet ports of LTE devices. ROS does not allow to assign interface queue on LTE interface itself.
What's new in 7.14 (2024-Feb-29 09:10):
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
Since this is only a defconf change, it did not seem important enough to update existing devices config. In my view, the advantage is either not really there or only marginal, if any.
It increases CPU load and limits max LAN throughput a little bit. This is what I could tell from btest.
It doesn't matter that LTE modem emulates ethernet device ... it's still not connected to (nor controlled by) switch chip. Hence the traffic to/from such interface is processed entirely in software. And that actually include traffic between LTE modem and ethernet interfaces, connected to switch chip ("downlink" traffic) ... and hence software queuing can make a difference.
I guess that the matter of different queueing algorithms is quite a lot a philosophical one. If it was strictly technical aspects, I don't believe there would be that many different algorithms out in the wild.
And if there's philosophical component in decission making, then decissions are (at least partially) matter of personal choice and hard to defend. Where the good people of MT tend to avoid jumping into discussions (and in rare cases where they do take part in discussions, they get flamed all over by users who see things differently than MT ... and I'm not taking sides in this sentence). And in the "not so technical" matters it's really hard to proove anything.
I needed to go back to my old AP as the Mikrotik had caused intermediate issues . WLAN was working but the Clients could not reach the internet nor another device. Normaly i would debug but as my wife is affected im now avoiding some other trouble :-).
Will now setup a dedicated WLAN only for testing. Lets see how this goes.
P.S.: All devices which had trouble were Apple Devices.
My Intel AX201 simply can’t stay connected to the hAP ax S.
But (!) after a week of troubleshooting, I have come to a workaround. So, if I ping a resource (with -t) or if I keep Winbox connected to the router, then the (Internet) connection doesn’t drop.
I had a somewhat similar symptom as @Behras but sometimes the wifi link also disconnects after 2-4 minutes, then reconnects back. Then after 5 minutes (or less) again no Internet and so on …
And yes, it is only because MTik have introduced these new wifi6 drivers, because my Intel card works perfect with hAP ac Lite (also on 5Ghz).
Hoping support will read this and if they need the troubleshooting steps I’ve made (a ton of them), I can send them the google AI chat link.
P.S. also tested the hAP ax S with AX211 and iOS 18 - works well.
Awesome, my hAP AX S hasn’t even arrived yet and I’m already questioning my choice. I bought the device to check out RouterOS and play with it before I commit planning with MikroTik routers/switches and maybe APs for my coming house.
I’ve read it before: wireless networking doesn’t really seem to be their strong discipline. Let’s hope after some software fixes all is fine enough.
So right now I should go directly on the testing instead of the stable build if I don’t want to have a subpar WLAN experience, right?
You've purchased a very new device with teething problems and these problems are dealt with in very new ROS versions.
You can hope (and probability of it happening is not small although not 100%) that with time problems will get fixed (or workarounds developed) and your hAP AX S will become a stable and well behaving device.
All good! That’s what I’m expecting and hope for, MikroTik generally has a great reputation regarding that!
For me it’s a device solely for assessing and playing around with RouterOS and deciding if I want to go this route or become a Ubiquity user in the future. I’m biased to MikroTik already when it comes to core routers and switches.
I took a device with WLAN just because there’s then more room to toy around.
I bought the device to check out RouterOS and play with it before I commit planning with MikroTik routers/switches and maybe APs for my coming house.