I use this command on syslogged traffic to see AP channel-change events.
fgrep -C0 -i -e interference -e "switch from channel"
Often what I see is an individual AP hopping back and forth between channels.
I do not use channelfly and I still have issues with APs changing channels. (due to "interference")
I have about 66 APs and I see 14 AP channel changes so far today. (between 4:30am and 1:50pm)
As far as I can tell, the Ruckus controller is not consulted and/or not very aware of where the APs are in relation to each other.
If it was, I'd prefer the controller to come up w/ a reasonable channel-plan and only make changes when the wireless environment changes significantly.
(When new APs show up or disappear)
Instead, whether ChannelFly is enabled or not, APs seem to make these channel-hopping decisions on their own, without regard to what the other APs on the controller are doing.
ChannelFly changes can be made in response to relatively short-term bandwidth usage changes. (like a large video download)
This results in unstable channel assignments where one APs channel change can trigger a channel change in an adjacent AP and in turn, that AP's channel change can trigger a change in the next AP, and the next.
(if anyone has a different understanding of this, please let me know)
I already hard-coded channel assignments in 8 APs in one building to cut down on this.
Once I turned on channel-fly (for a few hours) and the number of AP channel changes became ridiculous.
I did not get any end-user compaints but (as Keith points out) this is no proof that problems did not result.
Ruckus says this should calm down after a day, or a few days.
IMHO: ChannelFly is more of a "carrier" type feature, useful in metro-wifi deployments, or in known "dirty" wifi environments where you'd expect to be competing w/ other wireless APs, where momentary client outages are expected/reasonable, and having your APs pick non-standard wifi channels is a reasonable strategy.
In a "cleaner" "corporate" "enterprise" type environment, ChannelFly seems undesirable.
Speaking of metrics... I did a search on keith's name and "metrics" and got no significant results.
Also, I talked to a few resellers before making my Ruckus purchase re: some way (any way) to get an objective measure of how Ruckus wifi performed in my environment vs how the existing cisco stuff performed.
Other than the "you should try a whole bunch of clients at the same time" style of stress test I got no useful feedback.
(for example, how do I *know* that an auditorium full of clients is working or not when I *know* I can't count on any of them bothering to report a problem?)
If anyone has suggestions re: gathering metrics for Ruckus, cisco or other wifi networks, please let me know.