We have a 100% MikroTik network. When we run a speedtest while directly connected (Ethernet) to our gateway router, which is connected to the NBN on an FTTP service, we see expected results: Over 250 down, over 100 up. Three 10G fibre hops, a switch, a 1GB fibre hop and another switch later, those numbers are very slightly lower. All good. BUT: Connected via 5GHz wifi to an access point attached to the first of the abovementioned switches, we get the same download speeds, but only around 35 up. With essentially no other traffic on the wifi, the test device (a laptop) no more than three metres from the access point, and with no intervening objects. My thinking is this has to be a limitation in the test device's wifi or a limitation in the access point (MikroTik CAP aX). Not sure how to prove it one way or the other. We get the same result on three different laptops, but they are all similar vintage and same manufacturer (Lenovo). Is there any way this could be a *configuration* issue? It's very consistent. Am I ignorant of a known asymmetry in 5GHz wireless speeds? Hoping for ideas, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours.
I've had issues on laptops before with receive side coalescing enabled. Disabling that (a PowerShell command on windows) significantly improved wifi performance. ________________________________ From: Karl Auer via Public <public@talk.mikrotik.com.au> Sent: Thursday, 11 December 2025 12:01 To: MikroTik Public Cc: Karl Auer Subject: [MT-AU Public] Bandwidth oddity/problem We have a 100% MikroTik network. When we run a speedtest while directly connected (Ethernet) to our gateway router, which is connected to the NBN on an FTTP service, we see expected results: Over 250 down, over 100 up. Three 10G fibre hops, a switch, a 1GB fibre hop and another switch later, those numbers are very slightly lower. All good. BUT: Connected via 5GHz wifi to an access point attached to the first of the abovementioned switches, we get the same download speeds, but only around 35 up. With essentially no other traffic on the wifi, the test device (a laptop) no more than three metres from the access point, and with no intervening objects. My thinking is this has to be a limitation in the test device's wifi or a limitation in the access point (MikroTik CAP aX). Not sure how to prove it one way or the other. We get the same result on three different laptops, but they are all similar vintage and same manufacturer (Lenovo). Is there any way this could be a *configuration* issue? It's very consistent. Am I ignorant of a known asymmetry in 5GHz wireless speeds? Hoping for ideas, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours. _______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
On Thu, 2025-12-11 at 01:13 +0000, Michael Junek wrote:
I've had issues on laptops before with receive side coalescing enabled. Disabling that (a PowerShell command on windows) significantly improved wifi performance.
This appears to have the relevant incantation for Windows: https://twobyte.blog/blog/2024-11-02_disable_rsc/ Having less luck finding the thing for Linux (which is showing the exact same symptoms). Would you expect this feature to be enabled for wifi and not enabled for wired? Because a wired connection has no trouble uploading at the maximum speed allowed by the plan. And just the name - "RECEIVE side coalescing" - suggests it would slow inbound traffic rather than outbound. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours.
The issues I had mirrored yours (I'm thinking back in 2019 though). One direction was rubbish, and it was localised to the driver/firmware for the wifi adapter. I thought it was upstream, maybe I am misremembering. But hopefully it's something similar in your case. -----Original Message----- From: Karl Auer via Public <public@talk.mikrotik.com.au> Sent: Thursday, 11 December 2025 13:50 To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Cc: Karl Auer <kauer@nullarbor.com.au> Subject: [MT-AU Public] Re: Bandwidth oddity/problem On Thu, 2025-12-11 at 01:13 +0000, Michael Junek wrote:
I've had issues on laptops before with receive side coalescing enabled. Disabling that (a PowerShell command on windows) significantly improved wifi performance.
This appears to have the relevant incantation for Windows: https://twobyte.blog/blog/2024-11-02_disable_rsc/ Having less luck finding the thing for Linux (which is showing the exact same symptoms). Would you expect this feature to be enabled for wifi and not enabled for wired? Because a wired connection has no trouble uploading at the maximum speed allowed by the plan. And just the name - "RECEIVE side coalescing" - suggests it would slow inbound traffic rather than outbound. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours. _______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
My thoughts. If you have a mikrotik in the cloud, you can try a btest at a fixed send rate from the laptop to the cloud, and see if it seems to work ok, and to what speed. (If this works, maybe sort of hints at burstiness below) Perhaps the wifi for some reason is being bursty, and causing the internet output to overrun and drop packets while ramping up. Do you have a queue on your outbound interface? If so, is the bucket size small enough (0.01 maybe less) If not, perhaps try configuring one, (or shrinking the bucket size). Cake seems pretty easy and good. Conveniently interface queues work with fasttrack. (Though if you are marking packets you will likely need to add those marks to the queue) On Thu, 2025-12-11 at 01:13 +0000, Michael Junek wrote:
I've had issues on laptops before with receive side coalescing enabled. Disabling that (a PowerShell command on windows) significantly improved wifi performance.
This appears to have the relevant incantation for Windows: https://twobyte.blog/blog/2024-11-02_disable_rsc/ Having less luck finding the thing for Linux (which is showing the exact same symptoms). Would you expect this feature to be enabled for wifi and not enabled for wired? Because a wired connection has no trouble uploading at the maximum speed allowed by the plan. And just the name - "RECEIVE side coalescing" - suggests it would slow inbound traffic rather than outbound. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours. _______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au---------------------------- Roger Plant
-----Original Message----- From: Karl Auer via Public <public@talk.mikrotik.com.au> Sent: Wednesday, 10 December 2025 2:45 PM To: MikroTik Public <public@talk.mikrotik.com.au> Cc: Karl Auer <kauer@nullarbor.com.au> Subject: [MT-AU Public] Bandwidth oddity/problem
We have a 100% MikroTik network. When we run a speedtest while directly connected (Ethernet) to our gateway router, which is connected to the NBN on an FTTP service, we see expected results: Over 250 down, over 100 up.
Three 10G fibre hops, a switch, a 1GB fibre hop and another switch later,
numbers are very slightly lower. All good.
BUT: Connected via 5GHz wifi to an access point attached to the first of
abovementioned switches, we get the same download speeds, but only around 35 up. With essentially no other traffic on the wifi, the test device (a laptop) no more than three metres from the access point, and with no intervening objects.
My thinking is this has to be a limitation in the test device's wifi or a
the access point (MikroTik CAP aX). Not sure how to prove it one way or
Good morning! Watch out for CPU load caused by the test running! (look at cpu profile tool while you're observing unusually low results to make sure you're not pegging a cpu at 100%) Cheers! Mike. those the limitation in the other.
We get the same result on three different laptops, but they are all similar vintage and same manufacturer (Lenovo).
Is there any way this could be a *configuration* issue? It's very consistent. Am I ignorant of a known asymmetry in 5GHz wireless speeds?
Hoping for ideas, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
Please feel free to deal with this email during your own working hours.
_______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
On Thu, 2025-12-11 at 12:44 +1100, Mike Everest via Public wrote:
Watch out for CPU load caused by the test running! (look at cpu profile tool while you're observing unusually low results to make sure you're not pegging a cpu at 100%)
OK, will do. But it has no problem filling both directions when wired, would a wifi connection use more CPU? BTW it's the same with Windows and Linux, so probably not drivers. You don't mean the Mikrotik's (access point's) CPU do you? Say it isn't so! Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 Please feel free to deal with this email during your own working hours.
Hey Karl, I wasn't implying that the AP or client itself could be a problem (unless they are one of the endpoints of the test - I mean quite specifically the device that is running either the btest server or btest client - often, when folks try to test wifi throughput, they run it between the cpe (eg. SXT) and AP (e.g omnitik) which will often struggle with CPU load from the test, and, for that matter, potentially firewall. Due to the latter reason (firewall and filters etc) then it can also be 'instructive' to check all the intermediary devices too - you may have a whole bunch of logging rules or address list lookups in there that are causing cpu overhead. If so, then you'll see it as high percent usage on firewall (or other) in the profile tool. That's why I suggest to check profile tool rather than just 'system resource', as the latter only shows you load, and not what's using it all up : ) Cheers! Mike.
-----Original Message----- From: Karl Auer via Public <public@talk.mikrotik.com.au> Sent: Thursday, 11 December 2025 1:41 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Cc: Karl Auer <kauer@nullarbor.com.au> Subject: [MT-AU Public] Re: Bandwidth oddity/problem
On Thu, 2025-12-11 at 12:44 +1100, Mike Everest via Public wrote:
Watch out for CPU load caused by the test running! (look at cpu profile tool while you're observing unusually low results to make sure you're not pegging a cpu at 100%)
OK, will do. But it has no problem filling both directions when wired, would a wifi connection use more CPU? BTW it's the same with Windows and Linux, so probably not drivers.
You don't mean the Mikrotik's (access point's) CPU do you? Say it isn't so!
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
Please feel free to deal with this email during your own working hours.
_______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
Hey Mike, It sounds like Karl is using a public speedtest server rather than btest locally. Perhaps that's where the confusion is here... Regards, Dirk Bermingham -----Original Message----- From: Mike Everest via Public <public@talk.mikrotik.com.au> Sent: Thursday, 11 December 2025 4:54 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Cc: Mike Everest <mike@duxtel.com> Subject: [MT-AU Public] Re: Bandwidth oddity/problem Hey Karl, I wasn't implying that the AP or client itself could be a problem (unless they are one of the endpoints of the test - I mean quite specifically the device that is running either the btest server or btest client - often, when folks try to test wifi throughput, they run it between the cpe (eg. SXT) and AP (e.g omnitik) which will often struggle with CPU load from the test, and, for that matter, potentially firewall. Due to the latter reason (firewall and filters etc) then it can also be 'instructive' to check all the intermediary devices too - you may have a whole bunch of logging rules or address list lookups in there that are causing cpu overhead. If so, then you'll see it as high percent usage on firewall (or other) in the profile tool. That's why I suggest to check profile tool rather than just 'system resource', as the latter only shows you load, and not what's using it all up : ) Cheers! Mike.
-----Original Message----- From: Karl Auer via Public <public@talk.mikrotik.com.au> Sent: Thursday, 11 December 2025 1:41 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Cc: Karl Auer <kauer@nullarbor.com.au> Subject: [MT-AU Public] Re: Bandwidth oddity/problem
On Thu, 2025-12-11 at 12:44 +1100, Mike Everest via Public wrote:
Watch out for CPU load caused by the test running! (look at cpu profile tool while you're observing unusually low results to make sure you're not pegging a cpu at 100%)
OK, will do. But it has no problem filling both directions when wired, would a wifi connection use more CPU? BTW it's the same with Windows and Linux, so probably not drivers.
You don't mean the Mikrotik's (access point's) CPU do you? Say it isn't so!
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ Karl Auer (kauer@nullarbor.com.au, he/him) work +61 2 64957435 https://c.tfmcloud.au/zku1oe/PJdOiMu9gP1T75cQ mobile +61 428 957160
Please feel free to deal with this email during your own working hours.
_______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
_______________________________________________ Public mailing list -- public@talk.mikrotik.com.au To unsubscribe send an email to public-leave@talk.mikrotik.com.au
participants (5)
-
Karl Auer -
Michael Junek -
Mike Everest -
Roger Plant -
TFM Cloud - Dirk Bermingham