Has Ruckus running great since the start of term and today a class used a trolley full of laptops and half of them slowed right down to the point that logging on was painful. As soon as I was informed I took a screen shot of the AP in the classroom and it does show a dramatic drop in throughput. What could be causing this? The APs in use are zf7372
What code is the ZD on ?
What encryption does the SSID have ?
Are channels set to auto config, and if so, by background scanning or channelfly ?
Your not running tkip encryption are you, if so try aes as that is hardware accelerated in the ruckus gear. Also do the clients have 5Ghz ability, enabling both and steering it more to the 5Ghz range will give a better result as well as lowering the collisions from all having to use the same band and channel. You could also try and get a packet capture and see if one or more laptops has a damaged wireless card that is spewing rubbish. They could also all have their radios turned up really loud and the signal bounce alone would pollute the environment enough to cause collisions.
Further to SYNACK's post:
1) If your SSID is TKIP only, then the 802.11n data rates will be disabled as per the 802.11 standard (section 11 in the 2012 version). Change or create a new SSID. If you need to support older TKIP only stations create a seperate SSID mapped to the same VLAN.
2) Band steering is automatically enabled in Ruckus, you can only toggle on/off via CLI, so assume it's on.
3) If you are able to get a frame capture look for retry rate and CRC rates to indicate if there are layer 1 problems.
4) Power settings are also automatically set by the AP and the power settings are advertised in the beacons, so STA's should dynamically adjust power, especially when using higher data rates. Too much power wouldn't normally cause collisions, as the receivers can read the Frame Length field from the PHY header. If they also read the duration value then they set the NAV timer. If not, then they CRC error the frame. This is only a problem if the STA is waiting to transmit as it will raise the contention window leading to a longer wait time before transmit.
A noisy / damaged network card could well cause these issues, it's rare but not as rare as you may think. Microwave ovens do the same - are you sure the RF environment is clear ?
I didn't realize there was so much to it! The encryption is WPA2 AES and channels are all set to auto. On B/G(2.4 GHz) channels 1,5, and 10 are ticked others are off.
@neilmac Where do I find the channelfly setting?
@SYNACK All laptops are new and I expect the wireless cards to be on full power. Another class has the laptops now and they are working fine (see attachment).
On the performance graph the 5GHz band is unused and all clients are preferring to use 2.4Ghz band. How do I change this please?
Could easily be the room, if it has lots of reflective metal for the rf it may be bouncing around like the noise of letting off a firecracker inside a locker. If the other room is better from an rf perspective this could account for it, could even be a faulty ballast on some overhead lights but as the pollution seemed proportional to the number of clients I think it is something to do with them in that space. WiSpy is a great tool but rather expensive for the 2.4 & 5Ghz one.
Are you using 1,5,10,13 ?
Under services, look to see how the channels are set up.
The client card will dynamically adjust power, don't worry about the settings, it's usually not configurable.
What traffic were you pushing through the laptops when you had the problems ?
Multipath is a positive benefit to 802.11n, maximal ratio combining will aggregate signals to give a higher data rate, however if short guard interval is enabled then it can be problematic. We would need to know the environment, MCS rates in use and guard interval settings to know.
Right found it.
Under services Automatically adjust AP radio power to optimize coverage when interference is present is unticked and scanning for 2.4Ghz and 5Ghz are both set to background scanning.
It's not conclusive, tick it and see -
What ZD are you using ?
Next it happens, try and get as much info as possible, describe as fully as you can what went on.
Can you check the controller logs for the time it happened and see what it says ?
We're using ZD1106 and 188.8.131.52 build 50
You are about 3 revisions behind the latest code - I think 184.108.40.206 build 15 was regarded as the stable code for 9.5. The latest is 220.127.116.11 build 15. I wouldn't upgrade for the sake of it though, you should check the release notes and see what's fixed, then decide. If you do upgrade, make sure you take a backup first :>)
Have you not got support with your reseller or Ruckus HQ directly? The only reason I ask is because you should be kept in the loop by them as far as firmware upgrades go. They should also be able to answer any of your questions such as the above.
Agreed, or vendor was rubbish but Ruckus managed to sort out their mess in less than a day.
Originally Posted by CPLTD