Is Channelfly usable in real world scenarios?

[jeff_roback]

While ChannelFly is a truly remarkable technology, I'm wondering if people have found that it's usable in real-world scenarios.

For better or worse, Wi-Fi environments tend to be BYOD almost by definition, so we don't have too much control over what users show up with. And while one could work with people individually to update drivers, or have discussions about "It's not us it's them", the end result, in our experience has been end users saying "your Wi-Fi sucks", which is obviously the opposite of what we're trying to accomplish with a Ruckus deployment. (And according to Tom's Hardware it's supposed to be the other way around). In public Hotspot scenarios we'll never even hear from people whose connections didn't work, they just won't come back....

So I'm looking for guidance here from both Ruckus and from other VARs/Customers. Have you found that in anything but a completely controlled environment you safely turn on ChannelFly and have a high success rate with end users? If not, do you see this changing over time?

Either way it seems like it might be a good idea for Ruckus to put a whitepaper out there with this discussion. Customers or new VARs that are deploying this for the first time who end up with ChannelFly on by default are going to get an extremely negative first impression of Ruckus, which is really too bad because the technology overall is truly remarkable, but this one checkbox, in our experience, can change the overall experience dramatically.

Jeff

[primoz_marinsek]

AFAIK CF works fine. We've just had a big conference this weekend. 3APs in a basketball stadium, 2000 people, at peak 300 concurrent users and no calls for support. CF was ON the whole time.

But I too was not fond of CF when it was first implemented (FW 9.4 i think). It just didn't seem to work as it should. So I'd suggest using FW 9.6.1.

But here's a quote from Keith Parsons (CWNE #3). He's like a WLAN god of gods.

"Lack of end-user complaints about WLAN do not show how well WLAN works no more than complaints show it is a WLAN issue.
Use Actual Metrics!"

and

"Users complaining is a metric to know SOMETHING - but not WHAT is wrong. They blame Wireless first because it is unseen."

What kind of metrics have you used to say that RW is at fault. I can tell you from many personal experiences that it's almost always something but RWs fault.

[jeff_roback]

Thanks for sharing your experience with this. It's great to hear this is working better in 9.6.1. I've was scared off since the early revs and haven't tried it again since. Are you using it in 2.4 and 5.0 bands or just 5.0?

I agree with your complaints vs. metrics thoughts, but if end users are getting disconnected, I think fault is less relevant than options: It's kind of like kid proofing a home; if I can stick a cover over an electrical outlet to keep the kids from getting zapped, that's a win, even if it does decrease performance (take longer to use the outlet). So if I have a 'setting' to use (outlet cover) that keeps the kid from getting zapped, I'd rather do that than explain to mom that it's the kid's fault and the outlet is working as designed 🙂

So my overall thought is that if turning on channelfly will cause a certain % of byod users to have a bad experience, then I have to leave it off until a critical mass of end-users have the right drivers, etc to make it work. But based on your feedback it sounds like this isn't the case anymore, which is fantastic. Will be curious to hear feedback from others.

On a side-note, recent Intel driver releases seem to be so buggy (random disconnects, etc) that people are being forced to get current drivers anyway just to stay connected to any WiFi, so perhaps this will get this problem solved....

Jeff

[bill_burns_6069]

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.

-Bill

[keith_redfield]

Urgh? "Speaking of metrics... I did a search on keith's name and "metrics" and got no significant results. "

I'm 1.9 meters tall for the record.