Hi, let me comment on this setup. I’m just also trying to have my setups perform at best, and most is learned from theory and then tested with lots of trial and error. None of my settings are fully backed up with theoretical explanations but are always evolving as I get more experiences in. My backhaul is 4G in France, good and fast, but sometimes fully overloaded and even out for days. This makes the users go experimenting , like resetting AP’s and even unplugging them (and putting them back in a non-PoE port). This gives me AP tests with reduced coverage that I wouldn’t dare as experiment on innocent users.
As you know , i use no CAPsMAN.
Screenshot 1:
I’m missing CCQ as information. Sometimes the signal strength is OK, but with a very poor CCQ. (And it is not always because you pass a wall).
Signal strength looks good, the low 6Mbps/6.5Mbps rates are from devices which had no traffic yet.
Uptimes are rather short, but even then most volumes are much lower than expected.
No “sleeping” smartphones? You need “last activity” as column. That time will go up to 10 sec and then reset. (That’s why in my access-list “allowed out of range” > 10 sec)
Screenshot 2:
The cable plugging user allowed me to finetune the access-list values when there was poor coverage.
My basic setting with tipping point at -86dBm for 2.4GHz , and -83 dBm for 5 GHz has been adjusted FOR MY SETUP to -83 and -80, to make roaming more effective.
All power at the legal max value for ETSI. More than 50% of the devices select 5GHz. Only a seldom device flaps between 2.4 and 5 GHz.
(The 100+ devices are iphone, iPAD, Galaxy tablets, en a laptop here and there. I have no control as users bring them and stay for some days only)
Rising the basic rate reduces the number of access-list initial rejects, but is not very efficiënt in doing that. My hope was to use high basic rate only, but that didn’t work out as expected.
Screenshot 3:
Basic rates
12 Mbps as basic rate is the highest value I use. (Coming from 9 Mbps for several test months). No complains so far. (But I have no personal contact with the users, I only see that the same devices reconnect as before)
Supported rates
I would not use that 11 Mbps b-rate. There should be no 802.11b.
I do follow some recommendation of someone’s presentation (I forgot who) to allow lower rates than basic rates as supported. The rate will temporarily drop due to a failed packet transmission, and I do not want to drop that connection, if it is only a glitch. At the end, at beacon time, the higher basic rate will cause “no beacon received”. So I support ALL low rates.
Removing lower supported rates is a common practice in this forum. You want devices to use higher rates, OK, but forbidding the use of lower rates, is not the good answer to this in my opinion.
There are no access-lists to disconnect on lower rates, (and we know MT has no “airtime fairness” to mitigate the airtime consumption of those unwanted connections)
We only have signal strength … which leads to SNR … which leads to failed packets … which leads to CCQ … which leads to lower interface rates.
Dropping lower rates would be OK, if one had some “rate out of range” timeout.
HT basic MCS
This is very strict. MCS3 is 26-29Mbps ! This is a very high value. To be in line with the other basic rate limit, MCS1 (13-14.4) and MCS2 (19.5-21.7) should be allowed.
And there is nothing wrong with accepting MCS6 and MCS7.
Is basic rate only used in single stream? It looks like it is the case. (So HT MCS8 and up are not used)
HT supported rates
Same story as before. Support them all. You do not want those disconnects if it drops below 26Mbps for 802.11n just once.
VHT rates
802.11ac has taken away the discretionary rate accept/deny. So this is OK for 802.11ac. Not many of your clients go on 802.11ac however.
My experience only. YMMV.
