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

[bill_burns_6069]

Here's my unofficial (best guess) info:

Information from background scanning of other channels (if it even occurs) is not used to initiate a channel change when channelfly is turned off.
(note: I believe that channelfly does attempt to do some predictive stuff. i.e: if channel "n" was congested for the last 2 days at noon, then avoid being on that channel today at noon)

However, when "interference" is detected, an AP might decide to do a channel change and then do a quick background scan before making that change.

AFAIK: these decisions are made entirely by each AP without consulting other APs or the controller.

Time for another entry on the wish list:
I wish there was a mode where the controller had more "control".

[chris_roberts_5]

In 9.7 after channel fly runs for 10 minutes does background scanning start?

[john_blandford]

I think the new ability to turn ChannelFly off after a period of time may be a good solution. You should now be able to get the benefit of ChannelFly, but then effectively disable it from continuing (unless you want it to). My experience in hospitality has shown that still too many client devices do not always have 802.11h capability, which affects their ability to work well with the sometimes rapid channel changes caused by ChannelFly.

I am a big fan of ChannelFly, but find old client devices appear to be the weak link and those are the ones typically complaining of connectivity drop-outs when CF is running.

With this new control, you should be able to have your cake and eat it too. Leave CF run for a measured period of time, then disable it without having to remember to do it manually.

[jeff_roback]

I'm wondering if some of this behavior is hardware dependent. I've found recently that the 7363's seem to completely ignore the mtbc command. This is a big deal in standalone units since you can't turn channelfly off. We run into this when we're doing 1 or 2 AP's in very small SMB installs or executive residential installs where a ZD isn't practical.

Is there a CLI equivalent for the turn off after x minutes in the standalone AP's? If so I'll give it a try.

[keith_redfield]

Doesn't look like there's a CLI equivalent. Are you running the latest release? You can assign static channels - which has the effect of turning ChannelFly off.