R350 Poor 5GHz performance 200.16, 200.17, 200.18

[gritech]

Has anyone else experienced poor 5GHz performance on R350 APs on 200.16 and 200.17?  I briefly tried the 2nd version of 200.16 and both the initial and refresh of 200.17 with the same issue and went back to 200.15. However, I can't stay on 200.15 forever once security updates stop for it (they probably already have).  I have only R350 APs - 29 APs, ~200 concurrent client devices.

On both 16 and 17, I end up with estimated 25+% of my clients on 2.4 (normally only a handful of devices arriving/leaving the building) and those that are on 5GHz are at a lower data rate.  Also I received a lot of complaints about devices constantly disconnecting on 200.16 and all was fine when reverting to 200.15.

ex. an iMac that is stationary:

200.15.6.212.20:  AP Tx Data RateMCS 9/80/2 / 866.7M bps
200.17.7.0.152:  AP Tx Data RateMCS 7/20/2 / 144.0M bps

I have all channels manually set, but since the initial 200.16 release had issues with manual channels, I also tried auto channeling with no improvement.

I do not have band balancing or load balancing enabled; the clients overall do a great job of staying on 5GHz on 200.13, 200.14, and 200.15 also showing there is something off with 5GHz on 200.16, 200.17.

Another issue: on 200.17.7.0.152, when an AP is rebooted from the GUI, it goes to "upgrade required" instead of rebooting and gives the option to upgrade the AP.  However, the AP comes back online fine a couple of minutes later with no intervention.

[gritech]

I did some additional testing and created a new SSID leaving everything at default except auth method 802.1X, RADIUS servers, and Enable Dynamic VLAN.  All Radio settings were left at default.  The problem persisted on multiple devices based on reported Data Rate and client performance on speed tests.

In my above example of Data Rates, 200.17 reported a 20MHz channel, but on my 2nd test I confirmed some clients are reporting 80MHz channels, but at a low rate and with poor performance.

Again, reverting to 200.15 fixed the issue.

[gritech]

And the issue persists on 200.18 GA.  Same, reverting to 200.15 and all is well.

[gritech]

I think I have this solved...

The original 200.16 release had a lot of issues with pre-existing manual channel configurations.
IIRC 200.16 is also the 1st with 6GHz support, so likely a new WiFi driver.

All my APs had Channel, Channel Width, and TX Power (Full) manually set for both 2.4 and 5GHz.

Setting everything to Auto before upgrading from 200.15 seems to have solved the issue; setting to Auto after upgrading did not help.

I'll see how things look next week when my clients are back from the long weekend, but the stationary client devices are linking at normal speeds.

I'm trying 200.17.7.0.152; 200.18 had a lot of events for 'Application Reboot' every few minutes and I want to handle 1 issue at a time!

The reboot issue in the original post is not happening on my 2nd try of 200.17.7.0.152.

Also leaving channels auto with ChannelFly.  I had always just used the channel plan from the previous WiFi system since it worked well.

[harry_helpdesk]

Goodmorning,

Did your fix managed to fix this issue in the end? We are also on 200.15 and want to go to 200.16 or newer but in the past we also ran into the same issues with slow performance on 2.4 and 5 Ghz.