Use "Snooper" to scan that freq band.I don't have proper lab equipment (its from SXTsq 5 High Power), so i cant tell if its 802.11 decodable or not.
SXTsq 5 High Power is n only, so it will not see ac, but I agree that it can amplify signal as it is hi gain antenna. Its not how hot the signal is, fact that it constantly emits something is more important, as it shows that it is misbehaving. We have UAP-AC-HD Unifi dishes, they are +3dbi, but they are not the issue. When i started tik deployment I turned them off, to eliminate any issues whit multivendor env. They are not the cause of this.Use "Snooper" to scan that freq band.I don't have proper lab equipment (its from SXTsq 5 High Power), so i cant tell if its 802.11 decodable or not.
Snooper will give channels, AP and SSID, and client devices, as 3 levels of information.
It will recognise 802.11, nstreme and nv2 protocols (Not other brands specific protocols)
The SXTsq will AMPLIFY the received signal with is large antenna gain
-35dBm is near receiver saturation, what will cause all sorts of non-linear behaviour
EG. a wAP in the receive cone of the SXTsq often generates false radar detects, even if the frequency it uses is in a non-DFS channel. (I had phantom reception with 230MHz bias)
Unifi AP will probably be 3dB stronger than MT (MT is not using the TPC level EIRP , but only the 3 dB lower non-TPC EIRP levels)
Using "no_country_set" is moving to a country with fewer DFS channels, so fewer checks!
Klembord-2.jpg
Is what one expects to happen. But g/n/ac are compatible protocols.SXTsq 5 High Power is n only, so it will not see ac
A stupid question, but I have to ask, are you using capsman?I have setup with 30 caps and tops 300 clients and its pure mikrotik setup also getting same issues as in random radios crashes, need to reboot ap to come to senses, random speed drops..
Mikrotik just simple cant handle such dense setups and mix of clients..
As expected and should be using imo.Yea Capsman with local forwarding.
Just to be very clear. 802.11n cannot "wireless sniff" total 802.11ac packets, only the header is compatible, and that's what "Snooper" is analysing. That is also what regulates the air-time between transmitters.
I did tried sniffing a while a go and something wasn't right. Might revisit this as seeing ac would be beneficial.
"stand-alone" might be keyword here. Tonight might setup some APs as standalones.Just to be very clear. 802.11n cannot "wireless sniff" total 802.11ac packets, only the header is compatible, and that's what "Snooper" is analysing. That is also what regulates the air-time between transmitters.
I did tried sniffing a while a go and something wasn't right. Might revisit this as seeing ac would be beneficial.
All depends on setup and location and area. I have 30 stand-alone AP's in 3 subnets of the same network, for 400 client devices, plus 20 PtMP connections as interconnects, for 2 years now. No hickups, no reboots, no forced disconnects to clean up. Just a puzzle to be finetuned, including avoiding the other foreign 40 AP's.
When you see config in winbox is not that complex. I do packet marking (have to do in bridge as its L2), after that queues. Its a temp solution as network modernization is split in phases. I monitor networking devices whit Zabbix - resources are plenty, there is no buffer overflows etc.In the AP config ... Fairly complex queue handling, bridge filter, IP filter addition, packet marking ... I hope the AP processing power is not the bottleneck.
Setting priority does things internally, also for wifi WMM priority, but be aware of the lack of "AMPDU enabled" setting in MT by default for other priorities than priority "0",
No AMPDU aggregation for priorities 1 till 7 , if used, will waste a lot of air-time for everyone in the channel and drastically reduce wifi throughput.
I don't know if all those queue throttlings to the WLAN interfaces could not even break AMSDU aggregation by delaying IP packets, what would be a wifi throughput disaster.
viewtopic.php?t=165698#p912622 , viewtopic.php?t=165698#p912792
Removing 6Mbps basic rate can be good tuning, if needed. Otherwise it causes more disconnects and disables weak client associations.
(One AP/SSID at 6Mbps takes only 0.5% of available air-time in the channel. The old 1Mbps basic rate for 802.11b was 3% air-time, and that was often exhausted then with 30 AP/SSID)
Exactly that happened. I had the same thought, so I adjusted "frame lifetime" to 20sec on one of monitored APs (that I know often have this issue). Lets see what will happen.No activity for 3 min and the client did not drop the connection ? Reason code 4 (https://www.cisco.com/assets/sol/sb/WAP ... odes2.html)
viewtopic.php?t=159071#p787513
An AP will hold a frame to be transmitted for ever. (It will not drop that frame unless disconnected). Could this hold up a queue ?????
There is a "Frame Lifetime" in advanced tab of wireless interface, to drop old frames. Default is zero, never.
Something must be done in this case, stations will misbehave.What is "helping" here? The lingering packet is dropped after 20 sec. The connection is not dropped by the AP. It's up to the client to drop the connection if there is no activity.
I don't yet recommend Cambium.
...
MikroTik ... Has admitted in this forum over the years that there are some places and environments where they are absolutely not going to work ... As I have said for years ... If caps-man could control a good radio that could actually keep things connected... It would be my absolute go to favorite.
Indeed interesting. HW Frames are supposed to be the number of frames send/received. Frames the number of succesfull frames.Another interesting find.
From wiki: "hw-frames: Number of frames sent over wireless link by the driver.". Those are frames sent by interface itself (driver to be specific) and are not passed to network stack. So issues is, again, somewhere in driver itself. It could be somewhere between line you are saying. As you can see in picture, more that 3GB of traffic is sent to that station on hardware level, only around 150kb from network stack. It would be useful to inspect station that hangs AP and see what traffic is received. This station had bad signal, SNR 25db, rx signal level -80dbm. This is why higher rates and rx limits helps a bit, as this issue happens when signal level and quality is poor. But I have seen -50dbm station taking AP down, so it is not limited to low level signals, but its quality.Indeed interesting. HW Frames are supposed to be the number of frames send/received. Frames the number of succesfull frames.Another interesting find.
There is a setting in MT to handle failed HW Frames: HW Retries. Is 7 by default, can be set between 1 and 15.
Failed transmissions in the HW Retries range are not acted upon, except retransmitted.
If the HW Retries count is exceeded then the driver will lower the interface rate, or the number of chains (eg from 2S to 1S), and restart counting.
At the lowest rate the driver will retry during the "Disconnect timeout" every "On fail retry time".
"HW Frames/Frames > 15" is not expected unless all Frames fail. But then I expect the interface rate to be at the minimum supported rate.
What goes wrong?
Modified supported rates or basic rates creating unexpected behaviour? Default on 6 Mbps for lowest rates.
"HW retries" changed to 0 for some reason/bug, meaning unlimited failed retries?
Very long or zero (=infinite?) "Disconnect timeout"? Default = 30 sec. (*)
Very small "On fail retry time" ? Default = 0.1 sec. (*)
Interface rate is still higher than 6 Mbps.???
CCQ has not dropped to zero. ???
Signal strength is only given for the 802.11 speeds (6 till 54 Mbps). HT and VHT MCS are missing.
(*) Allows for 300 retries or [ 300 * ("HW Retries"+1) ] retries ???????
I have no issue with roaming, i have school with 30 APS i move around entire place and phone roams between 20+ APs and i run ping to gateway with my samsung phone and not single ping drops.UpRunTech
Do you set forwarding to local?
I was forced into an install yesterday that was really small
HAP AC2 + 2 cAP AC. RouterOS 7.7
No switch... The caps were connected directly to the hAP AC2 with POE Injectors.
Absolutely instant feed back of the roaming and signal levels of the test phone. A wifi call on 5Ghz didn't miss a beat as the tech walked around.
In the past I would set up netwatches and timers to disable radios in caps-man, to get packets moving again.
Reason code 8 : 8 Disassociated because sending STA is leaving (or has left) BSS https://aboutcher.co.uk/2012/07/linux-w ... son-codes/(received disassoc sending station leaving (8)), no way 10+ mix of devices decided just to leave AP for no reason while having full signal and no roaming.
Thats what I have seen for years at this point.
...clients are connected and show on registration table in capsman but you cant ping nothing in any direction, reboot AP or even just re-toggle from capsman, all starts working again...
Hint: Do not buy MikroTik cAP ac access points for office or campus environments. Those do not support 802.11ac MU-MIMO, no air time fairness, no 802.11k/v/r. Avoid CAPSMAN manager forwarding mode with thousands of clients."Hello,
the short version: CAPSMAN forwarding is full of bugs. The "fun" begins if you have ~1000 clients on the CCR controller, doing some traffice (500 Mbps/30000 sessions)...
Long version: No time today to tell you all things today.
So, let´s make it short:
- CCR will crash in certain high load situations
- CCR will disconnect all caps if you configure settings which let´s the CAPSMAN reprovision the CAP devices
=> They will disconnect an reconnect
On cAP ac clients disconnect, because 5 GHz interface is unstable. Some say the driver module crashes and reloads
Until:I don´t know whether this will solve your problems. Btw, do you also seee thousands of ~DHCP offer no lease messages in your logs?Version 6.46beta59 has been released.
*) ccr - improved general system stability;
*) wireless - improved IPQ4019, QCA9984, QCA9888 wireless interface stability;
=> Imagine you sit in front of one cAP, you can see.
=> Your notebook connects to the cAP but it doesn´t get any IP.
=> You disconnect and reconnect but your notebooks doesn´t get any IP.
=> You look on the DHCP server within the CCR and you can see the timer from the offer goes down from 30 seconds to 0 until it restarts at 30 seconds again. It stays on "offered" but nothing happens
=> Until you hit the provisioning button for the cAP and guess what happens your notebook gets an IP address immediately afterwars
=> Now you have this problem on 300 cAP device running on the CCR/CAPSMAN. Sometime the clients work without any problems for some hours until there is more load on the CCR. So starting at ~10:30 am each day I see "DHCP offer no lease" within the logs. 6.46beta59 doesn´t help. Noone knows why and I did everything this forum asked me to do.
=> The solution for me: Drop CAPSMAN, use single access points with local management and local forwarding. Sad? Of course.
The load was distributed to all cores on my CCR1036 devices with CAPSMAN based forwarding enabled.
I tested in my office openwrt a bit, also throughput. On 40mhz channel I got 140mbps down and feature set felt limited (I wonder why?!?).This is a repost from myself from last year:
"This was the main reason why I moved once from MikroTik to Aruba Network AP-5xx access points for high density and later to Grandstream GWN7660 for office environments, plus VRF lite for clients.
viewtopic.php?t=153735#p760146:
Hint: Do not buy MikroTik cAP ac access points for office or campus environments. Those do not support 802.11ac MU-MIMO, no air time fairness, no 802.11k/v/r. Avoid CAPSMAN manager forwarding mode with thousands of clients."Hello,
the short version: CAPSMAN forwarding is full of bugs. The "fun" begins if you have ~1000 clients on the CCR controller, doing some traffice (500 Mbps/30000 sessions)...
Long version: No time today to tell you all things today.
So, let´s make it short:
- CCR will crash in certain high load situations
- CCR will disconnect all caps if you configure settings which let´s the CAPSMAN reprovision the CAP devices
=> They will disconnect an reconnect
On cAP ac clients disconnect, because 5 GHz interface is unstable. Some say the driver module crashes and reloads
Until:
I don´t know whether this will solve your problems. Btw, do you also seee thousands of ~DHCP offer no lease messages in your logs?
=> Imagine you sit in front of one cAP, you can see.
=> Your notebook connects to the cAP but it doesn´t get any IP.
=> You disconnect and reconnect but your notebooks doesn´t get any IP.
=> You look on the DHCP server within the CCR and you can see the timer from the offer goes down from 30 seconds to 0 until it restarts at 30 seconds again. It stays on "offered" but nothing happens
=> Until you hit the provisioning button for the cAP and guess what happens your notebook gets an IP address immediately afterwars
=> Now you have this problem on 300 cAP device running on the CCR/CAPSMAN. Sometime the clients work without any problems for some hours until there is more load on the CCR. So starting at ~10:30 am each day I see "DHCP offer no lease" within the logs. 6.46beta59 doesn´t help. Noone knows why and I did everything this forum asked me to do.
=> The solution for me: Drop CAPSMAN, use single access points with local management and local forwarding. Sad? Of course.
The load was distributed to all cores on my CCR1036 devices with CAPSMAN based forwarding enabled.
=> I still have some MikroTik cap ac, wap ac left with CAPsMAN controller and local forwarding in places where only few clients will connect concurrently.
=> RouterOS is like a swiss knife, you can do a lot of things with it, even felling a tree, but using a chain saw is the tool you should look for if you want to make it right for reliable wifi
Nowadays there is an official OpenWrt port for MikroTik cAP ac devices (https://openwrt.org/toh/mikrotik/rbcapgi-5acd2nd_cap_ac). In different threads in the past there was once mentioned that single client throughput with openwrt is way lower than with RouterOS. But this isn´t what matters in a class room with 30 to 60+ clients connected on e.g. 1 cAP ac.
I haven´t tested OpenWRT with airtime fairness on CAP ac tested in a room full of students and asked whether the surfing experience was better than with a cAP ac and RouterOS as I´m simply tired of testing, perhaps someone here wants to.
As being already said before: Use 20 MHz channels, set static channel frequencies. lower the power for 2.4GHz so your clients always choose 5 GHz, ...
Messed whit mcs indexes?I am just some SOHO guy, but when I had customised rates enabled my WiFi performance was terrible. It would randomly drop speeds to 30Kbs on the 5Ghz channel.
Went back to default rates, and the problems are gone.
Probably you test it in router mode or/and without irqbalance package. As dump ap's, mikrotik with openwrt rocks.
I tested in my office openwrt a bit, also throughput. On 40mhz channel I got 140mbps down and feature set felt limited (I wonder why?!?).
Mikrotik support have responded to my ticket and now its ongoing process to, hopefully, solve this. This is is purely related how ROS handles wireless, so network stack, capsman or anything else is related. At least at this point off understanding. In short, main issue is stations not sending gracefull disconnect to AP (interface toggle, out of range etc.), so AP still tries to send data to it. tx-queue-drop increases and network will start to have hi ping or becomes unresponsive as buffer fills.
A workaround at this point (I was so close) is setting frame-liftetime=1 and hw-retries to 2 or 3. frame-liftetime=1 will clear buffer from stalled connections and hw-retries will reduce data rate faster, so stations will disconnect faster (this will impact roaming). Also acl rx limit helps, as a lot of low signal level stations causes this.
It's not way lower but it's way better. I'm a happy mikrotik customer with openwrt installed on about 20 mikrotik devices at work for more than 6 months. For me the alternative when i had Router OS with Capsman installed was to move to another vendor but i tried OpenWRT. 6 months later, not a single wireless problem. For anything else except wireless i use RouterOS.In different threads in the past there was once mentioned that single client throughput with openwrt is way lower than with RouterOS. But this isn´t what matters in a class room with 30 to 60+ clients connected on e.g. 1 cAP ac.
I haven´t tested OpenWRT with airtime fairness on CAP ac tested in a room full of students and asked whether the surfing experience was better than with a cAP ac and RouterOS as I´m simply tired of testing, perhaps someone here wants to.
As being already said before: Use 20 MHz channels, set static channel frequencies. lower the power for 2.4GHz so your clients always choose 5 GHz, ...
Thanks for all the information, they will be very useful to me shortlyAt this point best results are whit frame-liftetime=1, hw-retries=2 and in acl define minimums rx signal to -75dbm.
In the past I have tried everything, local, not local, TCP vs UDP and results were variable. It used to be the whole CAPSMAN system would just stall (not much Wifi traffic) when students moved about campus between classes and then it'd start to behave better after 10mins and some WAP reboots.Do you set forwarding to local?
Absolutely instant feed back of the roaming and signal levels of the test phone. A wifi call on 5Ghz didn't miss a beat as the tech walked around.
In the past I would set up netwatches and timers to disable radios in caps-man, to get packets moving again.
Firstly, I appreciate you taking the time to document this, since it's worthwhile getting more visibility on some of these issues. I too have been having a challenging journey with Mikrotik 11ac equipment.For last 4 months I am battling whit WiFi stability issues in our school...cap acs, hap ac2s, wap acs + other cool switching stuff.
There is no options to configure or turn on adaptive-noise-immunity on Capsman and its off by default.A few interesting points:For last 4 months I am battling whit WiFi stability issues in our school...cap acs, hap ac2s, wap acs + other cool switching stuff.
1. I suggest running without adaptive-noise-immunity=ap-and-client-mode since this will trigger radio microcontroller firmware paths presumably when certain conditions are detected by the radio phy (spurs/low SNR or similar); my guess is this will adjust some phy parameters like sensitivity or filtering. It seems reasonable to assume some of these mechanisms aren't mature as are seldom used, therefore possibly making the radio 'deaf'; this could be scenario #2 you experience. The strong transmission observed could be many retries as the radio doesn't hear the ack.
That's a very thorough list, thanks for posting!Firstly, I appreciate you taking the time to document this, since it's worthwhile getting more visibility on some of these issues. I too have been having a challenging journey with Mikrotik 11ac equipment.For last 4 months I am battling whit WiFi stability issues in our school...cap acs, hap ac2s, wap acs + other cool switching stuff.
A few interesting points:
1. I suggest running without adaptive-noise-immunity=ap-and-client-mode since this will trigger radio microcontroller firmware paths presumably when certain conditions are detected by the radio phy (spurs/low SNR or similar); my guess is this will adjust some phy parameters like sensitivity or filtering. It seems reasonable to assume some of these mechanisms aren't mature as are seldom used, therefore possibly making the radio 'deaf'; this could be scenario #2 you experience. The strong transmission observed could be many retries as the radio doesn't hear the ack.
2. I believe the non-opensource/proprietary WiFi driver here doesn't have airtime fairness and I find low-throughput clients are easily starved by high-throughput clients. Mikrotik's default radio interface queuing discipline SFQ appears to workaroud the issue (perhaps at the expense of aggregation). I suggest using SFQ on the radio interface and performing QoS on the router.
3. The cAP DSCP to WMM mapping is good, however you need to use "/ip/firewall/mangle/set new-priority=from-dscp-high-3-bits" to get the correct mapping; since packets will use radio queues beyond 0, aggregation may be disabled which can hurt air throughput unless you use ampdu-priorities=0,1,2,3,4,5
4. I do recommend putting the user network onto a VLAN (you'll need "/interface/bridge/settings/set use-ip-firewall-for-vlan=yes") to reduce broadcast traffic with
5. Since local forwarding is used on the cAPs, you might be better off managing the layer 2 broadcast domain via bridge horizon
6. I recommend CAPsMAN security group-key-update=1h and disable-pmkid=yes for optimal compatibility with Apple devices (unless things have changed since RouterOS 7.2)
7. There can be quick signal fluctuations due to occlusion so I recommend allow-signal-out-of-range=45s
8. I recommend not having AP and station mode on the CAPs, since this will have less exposure; instead deploy a powered device you can connect and ping
9. You may want to compare "/caps-man/configuration/set hw-protection-mode=rts-cts" vs none
10. I found '/caps-man/configuration/set multicast-helper=full' caused broadcast and multicast traffic to get blocked on a deaf station, so ensure this is set to disabled.
It would be good to see what issues remain with these adjustments on RouterOS 7.8. Beyond that, capturing a supout and decoding to get the WiFi kernel logs may reveal other useful information including radio queue lengths, packets queued per station and related.
Thanks,
Daniel
CAPsMAN overrides the local cAP interface configuration, therefore on the cAPs, use "/interface/wireless/set adaptive-noise-immunity=none ampdu-priorities=0,1,2,3,4,5" when not connected to CAPsMAN. You may want to also specify aggregation on WMM priorities (which map to radio queues) 6 and 7 also to protect against heavy traffic consuming airtime.There is no options to configure or turn on adaptive-noise-immunity on Capsman and its off by default.A few interesting points:
1. I suggest running without adaptive-noise-immunity=ap-and-client-mode since this will trigger radio microcontroller firmware paths presumably when certain conditions are detected by the radio phy (spurs/low SNR or similar); my guess is this will adjust some phy parameters like sensitivity or filtering. It seems reasonable to assume some of these mechanisms aren't mature as are seldom used, therefore possibly making the radio 'deaf'; this could be scenario #2 you experience. The strong transmission observed could be many retries as the radio doesn't hear the ack.
To get more aggregation, one could increase sfq-allot to the aggregation limit, however lack of airtime fairness might be problematic for DHCP at least; remember Mikrotik probably use SFQ in all their validation.Very interesting list @DanielJB
Can we do better on aggregation? SFQ parameters or other queue type?
Lack of good aggregation wastes a lot of valuable air-time.
One the cAP, use (eg) "/queue/type/set wireless-default kind=cake cake-flowmode=dual-dsthost cake-diffserv=diffserv4".You cant change wireless interface queue type while its managed by capsman.
Difficult to see the AMPDU aggregation, as I understand it is at the driver level. Even my dedicated wifi-sniffing-dongle did not show me the aggregation (as I don't know where to look for the AMPDU size used.)It would be good to get some site testing and feedback on this actually.
Hi. Thanks for joining discussion, to answer to your points:Firstly, I appreciate you taking the time to document this, since it's worthwhile getting more visibility on some of these issues. I too have been having a challenging journey with Mikrotik 11ac equipment.For last 4 months I am battling whit WiFi stability issues in our school...cap acs, hap ac2s, wap acs + other cool switching stuff.
A few interesting points:
1. I suggest running without adaptive-noise-immunity=ap-and-client-mode since this will trigger radio microcontroller firmware paths presumably when certain conditions are detected by the radio phy (spurs/low SNR or similar); my guess is this will adjust some phy parameters like sensitivity or filtering. It seems reasonable to assume some of these mechanisms aren't mature as are seldom used, therefore possibly making the radio 'deaf'; this could be scenario #2 you experience. The strong transmission observed could be many retries as the radio doesn't hear the ack.
2. I believe the non-opensource/proprietary WiFi driver here doesn't have airtime fairness and I find low-throughput clients are easily starved by high-throughput clients. Mikrotik's default radio interface queuing discipline SFQ appears to workaroud the issue (perhaps at the expense of aggregation). I suggest using SFQ on the radio interface and performing QoS on the router.
3. The cAP DSCP to WMM mapping is good, however you need to use "/ip/firewall/mangle/set new-priority=from-dscp-high-3-bits" to get the correct mapping; since packets will use radio queues beyond 0, aggregation may be disabled which can hurt air throughput unless you use ampdu-priorities=0,1,2,3,4,5
4. I do recommend putting the user network onto a VLAN (you'll need "/interface/bridge/settings/set use-ip-firewall-for-vlan=yes") to reduce broadcast traffic with
5. Since local forwarding is used on the cAPs, you might be better off managing the layer 2 broadcast domain via bridge horizon
6. I recommend CAPsMAN security group-key-update=1h and disable-pmkid=yes for optimal compatibility with Apple devices (unless things have changed since RouterOS 7.2)
7. There can be quick signal fluctuations due to occlusion so I recommend allow-signal-out-of-range=45s
8. I recommend not having AP and station mode on the CAPs, since this will have less exposure; instead deploy a powered device you can connect and ping
9. You may want to compare "/caps-man/configuration/set hw-protection-mode=rts-cts" vs none
10. I found '/caps-man/configuration/set multicast-helper=full' caused broadcast and multicast traffic to get blocked on a deaf station, so ensure this is set to disabled.
It would be good to see what issues remain with these adjustments on RouterOS 7.8. Beyond that, capturing a supout and decoding to get the WiFi kernel logs may reveal other useful information including radio queue lengths, packets queued per station and related.
Thanks,
Daniel
No, not yet. My task was make APs to hang, but its not that easy to do. Now I have quite optimized schools network and i cant let loose all configs, as a result schools learning process will be interrupted. I managed to hang once of APs, but no response from support.@maigonis did you hear anything from Mikrotik since the cAPAC stopped working properly recently?
It is not density issue, its stations not sending graceful disconnect. It mostly happens in dense networks, yes, but it affects also home users. Just more rarely.As I state all the time...
I have an email from Mikrotik support saying they know about the density problem. And will get back to me when they have a fix.
It's dated 06/10/2019
General note - if no one complains that does not mean there is no issues. WiFi quality can be quite bad, but if users requirements are met he does not complain (for example LTE link quality can be really bad, but if you can open Instagram and TikTok you are fine). So monitoring and more detailed testing is recommended.I've got an apartment complex we manage. It's got 65 units on 4 floors. We installed Mikrotik AP for each unit, hapAC2. I came up with a channel plan, that put adjacent rooms - Right left top bottom and across the hall on different channels to minimize interference and came up with a scheme to apply to each unit. Then the same pattern is staggered slightly for the room across the hall. And staggered, each floor, so Ideally there are very few if any overlapping channels. Seems to work. Here's the config for each unit.
A, B, C, D were the patterns
Attached are the templates we used for each that seemed to work, and allowed up to 250mbit on the 5 G interface. Had to go into each unit and actually label the apartment number, but that's it.
For what it's worth, we don't have any complaints about the wifi at this building. and I've had the experience downtown where wifi won't work more than 5 ft from and AP due to everyone in the building using the same channels with high powered devices.
So with the first apartments, the one across the hall would be on a different channel, and the ones that are adjacent to each are on two different channels. Then the apartments below would be staggered, and the apartments above on the same staggered pattern.
Hi,After a client (School) who had Mikrotik AP's contacted me about intermittent wifi speed I did some investigating and testing.
The largest speed killer I found was the SFQ interface queue set on the wireless interfaces. All it takes is one client with bad signal trying to communicate and then all the other connections' speed is dropped to it's level. Prefered to set it to none.
AMSDU should also bet set much smaller than the default depending on how noisy the environment is.
Further than that is the same optimizations you would do with other brand PA's. Channel width, manual frequencies etc.
Actually with these options set Mikrotik's AP performance isn't bad. These AP's are CAP AC's and considering that they are SU-MIMO the performance is what you would expect.
Wow... Hope you have a lot of thick walls between WAPs.65 AP's and router is RB5009.
1400 clients peak.
I recommend deploying APs in whole building, for example in halls. It will eliminate issue when stations connect to AP thru walls. If a station connects in these conditions then this will accelerate "graceful disconnect" issue and drag that APs performance down in general, because of bad modulations and TX retries. Yes, ACL whit RX limit do help, but if station count is large that does this you will still notice it. Airtime in classroom env is precious, so you have to use it wisely.Concrete / Brick walls. They only care about wifi for learners in classes.
Im marking topic solved, but will try update if something meaningful will come up.Wave2 stability, performance and feature set is now in line whit hardware capabilities, better late than newer. Since first beta I'm testing (carefully whit understanding what I'm doing and having backup plan) ac wave2 in almost 900 students school, we daily have 300-400 STAs connected. WPA3 can and is causing issues, so I recommend starting upgrade whit "legacy security profile" - WPA2 only, MFP off, to be sure and learn how wave2 works as it brings changes.
To summarize my findings: There is no more "graceful disconnect issue", this was major stability issue, mostly noticeable in larger networks. Performance wise 40mhz channel can push around 140-160mbps under load, tested whit 32 ipads updating at the same time. All STAs that do support 2x2 will connect 2x2, and modulations are holding great (will depend on your env and deployment). Also noticed noticeably lower latency/jitter, network in general is more responsive. Wave2 features (802.11kvrw, beam forming, WPA3 etc) bring even more improvements, mostly noticeable in hi density (again) networks, but also smaller networks will see benefits, especially WPA3. As a feature request I would like to see channel utilization stats in capsman, also be able to collect them whit SNMP, so I can see actual ch usage over time. Also radar detect still needs improvement (Mediatek MT7921au based wifi cards still trigger DFS event almost on every interface toggle, also ax lineup), so for now I cant set Latvia as country, again US works like it should, but incorrect country is causing issues, so not recommended. Rate altering would be great, to cut BPSK and QPSK for example, again, useful in hi dense networks, so I can leave ACL RX limits alone (mostly).
Really happy too see wave2 on ac (arm at least) lineup, it brings a lot of stability, performance and feature improvements. To be clear, till stable is released I don't recommend updating larger networks if you don't monitor them and/or don't have knowledge how to do so, but this brings those device further. They now do work whit the same capsman, so you can mix whit ax lineup, even if you are in transition phase.
Great job boys/girls.