Channelfly and rapid channel changes

[john_d]

I live in a big apartment complex, so I really conceptually like ChannelFly, especially on 2.4GHz. I've traditionally run it in run-stop mode, but I decided to try leaving it running for a longer period of time, since the marketing documentation for Channelfly claims that the channel change rate should dramatically fall over time. I've also played with changing the MTBC option (from the default 100 minutes to 200 or 300 minutes).

After around 30-40 hours of Channelfly uptime, I'm still noticing frequent channel changes, and more peculiarly, the channel changes occur in bursts. On 5GHz, where the RF is pretty quiet, it seems to bounce back and forth between two 5GHz channels every 6 hours, which is pretty consistent with my 200-300 minute MTBC setting.

However on 2.4, I find that once every 2 hours it seems to rapidly change between a large number of 2.4GHz channels, and this rate has not seemed to settle down at all. Is ChannelFly eventually supposed to converge to a stable selection of channels? Or is this kind of constant hopping expected?  I guess I might be better off going back to run-stop mode.

Here's an example of the channel hopping I've seen from the last 24 hours across 3 AP's:

[michael_brado]

Channelfly is designed to better utilize the entire frequency band, and will respond to changing environemental RF.
As you mention, you're in an apartment building where you likely have many neighbors also using 2.4g.
If you have modern clients, 802.11k (announce new channel to clients roaming away), with 802.11r (fast BSS transition)
facilites changing channels with the AP changes.
Only if you sense that your clients are having any problems or disconnects, then you might consider turning CF off.

[john_d]

Thanks, Michael. It sounds like, reading between the lines, is that this is the expected behavior of ChannelFly, and changing the MTBC won't stop the rapid back-to-back channel changes when it decides the current capacity is low.

For the most part, my modern clients do indeed deal well with roaming for most workloads. I've found however that sometimes the rapid back to back channel changes will cause a client to disconnect and reconnect, especially if they are in the middle of AirPlay mirroring or a VOIP call or some other latency sensitive activity. 

I'll have to ponder more about whether I'd like to keep CF on or off, or maybe just use it on the more crowded 2.4GHz, which the problematic clients rarely use. I really like the benefit of being able to dynamically react to RF changes instead of doing run-stop.

[bill_burns_6069]

Here's a related question:
https://forums.ruckuswireless.com/ruckuswireless/topics/is_channelfly_usable_in_real_world_scenarios