I'm currently investigating a way to compare a scenario with an AP that supports Wi-FI ACS (auto channel selection) against an AP that do not support the ACS mechanism. The goal is to prove that an ACS mechanism will improve the stability and speeds obtained for all STAs. Any idea how to test this?
You need a bunch of APs in a quiet RF environment. Set up part of the APs as a test network. Observe stability and speed in original state with and without ACS. Configure the rest of the APs as a competing network (or networks) on interfering channels. Observe stability and speed in the test network with and without ACS. Change channels on the competing network and observe again.
The problem with trivial ACS implementations is that if the APs are started at the same time, say after a blackout, they may see exactly the same channel as the best available. All of the APs are listening at the very same moment so none of them has yet chosen its channel. In the worst case they all end up on the same channel. Many ACS implementations won't switch channel after the first choice since it may disrupt service. Even if there is a channel reselect timer it may set the APs to reselect the channel at the same time without any randomization – and the APs are again on the same channel. If the APs are powered by a PoE switch they are started at the same time.
The best approach to ACS is to use some central logic to prevent APs from selecting the same channels. A distributed solution could observe other channels during use and only switch channel when there are no clients associated and after a random delay. This could however still trigger another AP to switch channel and then the next, which could lead to an unstable network. Also, an always-on client (like a printer) would preclude channel switches.
If the RF environment is unstable to begin with, ACS could cause more trouble than worth. For example several users walking around with personal hotspot turned on on their smartphones can wreak havoc. I have a client who is close to a railroad and every passenger train appears to have its Wi-Fi on a different channel. Same goes for buses, if you have long haul bus routes running by the office. Of course you can simulate these in your lab environment and see how your ACS performs.
Thanks @Petri :)
Whats is your suggestion for to observe stability and speed?
I'm thinking to use the following:
- Stability - Ping (Drops %, RTT)
- Speed - iperf3
Do you have other suggestions?
iPerf will report losses and RTT as well. I can't think of any use for ping if you are also using iPerf.
You should also include jitter in the stability evaluation.
I would consider logs from the RRM system. If the channels keep changing and power levels fluctuate it is a stability issue IMO.
I have not seen any logs from RRM so I can't comment on them. I would tend to believe that its logs would at least be slightly biased towards making RRM look good - after all, you paid for it and Cisco wants you to be happy with it..
This is not a dig at Cisco, as I know that many big companies do it. The same goes for performance data, and is why you want a neutral third party to run comparison tests.
Anyway, back to tools. There is a little tool called MultPing that I have been using for several years. Given it's low price, you should really give it a look. Mine is an older, purchased version, so I don't know their current prices, but I think they still have a free run-time time limited version that you should be able to download and try.
It takes a bit getting used to the output controls, but it is well worth the effort.
I believe @lealog is using ExtremeMobility equipment, not Cisco. I introduced the Cisco term RRM. Lealog used ACS and that's how Extreme refers to their implementation. I am not at all familiar with Extreme. I just imagine that the system would log all events like channel and power level changes. Those shouldn't occur often after the initial deployment, however. If they do, it is a stability issue.
How funny. Zebra Technologies sold off the old Motorola AP technology to Extreme Networks almost two years ago. I have not seen anything of theirs since then.
I would bet that any RRM type technology has variable reporting/calibration periods - not that the mfg's, let customers "play" with those settings. You sure don't want the network thrashing because periods are too short, or too many support calls because the customer has messed up the settings.