Terribly slow Wi-Fi speed

Sometimes we suffer from terribly slow Wi-Fi speed down to 5Mbps on 5GHz channels.
We use Mikrotik router (with RouterOS 6.49.6) with CapsMan for managing 8 cAPs (Miktotik cAP AC) with roaming enabled. CapsMan configuration is attached.
Normally we get 100-200 Mbps on laptop connections, but sometimes laptop connections drop to 5-10 Mbps on one cAP or another. All laptops connected to that cAP suffer the same slow connection. Meanwhile we have never seen more than 20 clients connected to any cAP at once. Furthermore, number of clients does not influence cAP. I tried switching clients off cAP that suffer from terrible slow speed and ended with single client still suffering slow speed. Others laptops connected to other cAPs are not effected. We have noticed that 3 of 8 our cAPs sometimes drop their speed in that manner. After a while (ten minutes or half an hour) cAP regains speed to normal 100-200 Mbps. Sometimes we have no time to wait and hard reset cAP. After hard reset cAP always works fine with normal 100-200 Mbps.

What may be a culprit or what should I examine else ?
Thanks in advance for your help.
capsman.rsc (3 KB)

This is how wifi works, and is supposed to work.
There might be a clear reason why the speed drops (wall’s, distance, interference).
If transmissions fail, wifi retries 7 times, but if still no success the interface rate is lowered to compensate.
Wifi will slow further down until it works or until it disconnec,ts (really fails in that setup at the lowest rate)

These actions can be monitored in the “Registration table” (interface rate, and CCQ value based on needed retransmits)
Multicast/broadcast packets are always sent at the basic rate, by default only 6 Mbps, because there is no “check and retransmit” mechanism.

The impact of a slow connection (eg sticky client holding on to the current AP too long even when there is a better one nearby. The client decides where to connect, not CAPsMAN) is felt by every transmitter in the same channel, (That is more than the same AP) because there can only be one transmitter at the same time in each channel.
And a slow transmitter will occupy the channel for a much longer time, than the fast transmitter. Bringing the effective speed down for everyone in the channel.

Restarting a cAP will force its clients to check for a better AP. Any sticky client will probably roam then, and be at full speed until moved while remaining sticky.

From your configuration I would like to give you the following hints/tips:

  • Don’t use 802.11a neither 802.11b
  • Don’t use extension channel on the 2.4GHz radio
  • Consider using 40MHz bandwidth on the 5GHz radio
  • Specify your channels explicitely
  • Don’t use tkip

And furthermore…don’t share a config that might still contain a passphrase

try ROS 7.6

Thank you for detailed answer. Please, clarify:

Can we get evidence of transmission failures other than Tx/Rx rate ? Maybe, sniffering AP traffic ? I know about TCP retransmissions, does Wi-Fi work in the same manner ?

Does it mean that streaming multicast video always flow at 6 Mbps ? I am confused.

We use the same channel Ceee (actually I always see 5180) on all our APs. As far as I understand from your explanation all APs must slow down in case of single slow client on any of AP. But we noticed different behaviour: all clients on the same AP work slowly while clients on other (nearby) APs work fine at 100-200 Mbps. Maybe, I misunderstood you.

Thank you for your answer.

Does it mean that Wi-Fi AP will refuse to connect old Wi-Fi clients that support only 54Mbps ?

Currently all APs share the same Ceee channel. How should I specify Wi-Fi channels properly ? Can I set different channel for each AP using CapsMan ? Will roaming work if adjacent APs have different channels ?

If you mean by old ancient…yes

Interference will always have to be avoided…sharing the same channel is the worst you can do. When I used CAPsMAN (years ago, so I have to answer by heart) I made a configuration per radio. That way I could specify everything per radio.

Roaming will definitely work better when using different (non overlapping) channels.

Can we get evidence of transmission failures other than Tx/Rx rate ? Maybe, sniffering AP traffic ? I know about TCP retransmissions, does Wi-Fi work in the same manner ?

Yes there is detailed information , ratio of frames (good transmissions) versus HW frames (all transmissions) leads to calculate TX CCQ.

Does it mean that streaming multicast video always flow at 6 Mbps ? I am confused.

Yes and no. There can be multiple basic rates defined. Which one is choosen, I don’t know the algorithm.
Mostly using multicast for much traffic kills the wifi environment. Be aware that Apple Bonjour, mDNS, some camera streams all are multicast.

Multiast will be avoided if “Multicast helper” is set to “FULL”, by converting multicasts in unicasts per device.

We use the same channel Ceee (actually I always see 5180) on all our APs. As far as I understand from your explanation all APs must slow down in case of single slow client on any of AP. But we noticed different behaviour: all clients on the same AP work slowly while clients on other (nearby) APs work fine at 100-200 Mbps. Maybe, I misunderstood you.

I have just given the working principle. If another transmission is detected on the same channel, then the other transmitters all will WAIT. APs and stations are equal in this.
Will it be detected? Depends on the signal strength and quality. Sometimes even -96dBm is still decodeable.
So your experience depends on the distance for one parameter. A slow transmitter disturbs the whole channel when transmitting very often, or continously.
Only one AP slow, e.g. could be disturbed by its own reflected transmissions.

Half overlapping channels will not be waited for, but the signal will be distorted due to adjacent channel interference. Corrupting the packet and causing retransmits for both channels.
802.11ac is a bit special in this, where the C and e 20MHz channels are handled differently. (Look up the theory: https://www.oreilly.com/library/view/80211ac-a-survival/9781449357702/index.html )

One very interesting tool with MT is “Snooper”, that will show AP and clients on the channels. The Wifi Sniffer there will even show all the packets. To be analysed with Wireshark. The multicast Beacons are very interesting to analyse.

sharing the same channel is the worst

Channel overlap [adjacent channel interference] can be worse than same channel co-existence. [Same channel interference], because the former destroys transmissions, the later make them wait for each other. WMM defines the priority in that wait state. WMM and MT is yet another story. (activated by default, but everything is the lowest prirority by default config).

Fully agree with tips from @erlinden. Important tips!

802.11n (HT MCS rates) and 802.11ac (VHT MCS rates), are fully backward compatible with 802.11g (6-54Mbps data rates)

Roaming works fine with different channels. The station seeks to find the SSID.

What a compliment! And thanks for learning from you again!

Seek another vendor for WiFi.

As a recovering caps-man addict
I miss caps-man speed of setup, tight integration, flexibility… BUT I SURE DON’T MISS THE CONSTANT COMPLAINTS AND TROUBLE TICKETS.

Just to add to the answers from @bpwl and @erlinden:

(1) from a quick review of your config, I'd suggest you change "local-forwarding=no" from no to yes to eleminate one potential source of the slowing-down problem. Does the CPU load on the CAPSMAN router/controller jump up during the slowdown? Perhaps it's not a factor in the slowdown, but I personally avoid CAPSMAN forwarding if I can. You may have to reconfigure your network, though. for the change from CAPSMAN forwarding to local forwarding, depending on your network config.

(2) Also I'd suggest you keep the bandwidth at 20Mhz for the 5Ghz while trying to determine the source of the wireless problem; you may go back to 40Mhz when you've isolated and solved the problem.

I wish you all best of success;
Best Regards and Best Wishes.

Use wave2, legacy drivers have issues that pop up on larger networks quite often.