Slow connections from zf7982

[brant_hyatt]

Hello,

I'm relatively new to ruckus gear.
We have 30 zf7982s in 3 non-overlapping areas.
The short version is that i'm only getting 11g speeds even when clients connect at 11n (2.4 or 5ghz).

I've taken an ap and restricted it to 11n mode but that didnt make a difference.
I'm using the speedflex testing tool (android) for the bandwidth test.
All wlans are using wpa2-psk, without any bandwidth limiting configured.
Seeing speeds of 40-50mbps.

Thanks for any help!

[john_d]

If your devices are 1-stream that you're testing with, then 40-50mbit of observed speed is pretty normal for 2.4GHz and possibly 5GHz if you are limiting to 20MHz channels for high density rollouts. 150mbit/300mbit are theoretical wifi signaling rates, and real-world peak TCP/UDP transfer rates are maybe 50-60% of the signaling rate.

So, can you confirm whether you've got 20 or 40MHz channel widths on 5GHz, and what kind of Android devices are in use (e.g. whether they are 1 stream or 2/3 stream)

[michael_brado]

And confirm that your WLAN is configured with straight 'WPA2' Method (not WPA-Mixed), with 'AES' Algorithm (not Auto)? If you include Auto with TKIP, you will drop
from 802.11n to only 802.11b/g, and limit the overall number of clients supported.

[brant_hyatt]

Thanks for the responses!
Yes, I am testing with 150mbit devices. And a 300mbit laptop using pcattcp.

I have the width set to auto. The advice we were given was to leave as many settings to "auto" as possible. Should I force it to 40?
And yes, definitely have WPA2 with AES on all wlans.

[john_d]

Thanks for confirming. The width on Auto and WPA2+AES is perfectly fine. Auto does 20MHz on 2.4 and 40MHz on 5GHz, which is what you want. Fat 2.4 channels are a bad idea and most clients will even advertise they are fat-intolerant anyway.

So, on 2.4, 40mbit or so is generally the peak I see from 1 stream ("150 mbit") devices, and on 5GHz, I can see 80mbit thanks to 40MHz channels. But that 80Mbit is on a good day with the right testing app and provided the wifi is not dumbly implemented on the device itself (you wouldn't believe how many mobile devices have bandwidth and latency bottlenecks between the wifi stack and the rest of the system)

Have you ever seen better than 40-50mbit from these devices with other AP's, including consumer ones? Do you get substantially worse than 40-50mbit from more than a couple feet away from the AP?

I'd also try to rule out poor client roaming choices. Set up a test environment with just ONE AP, one band at a time, and stand close to the AP and repeat your bandwidth test. If that performs better then it's likely your clients are associating with a far away access point, and there are some ways to work around that.

Honestly, for the devices involved, I think you are seeing fairly acceptable speeds from them. If you want something faster, I would really demand that your clients be MIMO, at least 2x2 (gets you 80-100mbit real throughput) or 3x3 (gets you 150-175mbit real throughput). Or 802.11ac -- if you upgraded to R500/R600/R700, you could see 20-30% higher speeds from the efficient 256QAM modulation scheme, and generally speaking 802.11ac wifi devices are architected to support the faster speeds with the appropriate internal bus architecture that allows those speeds.

P.S. On a related note, if the bulk of your devices you want to support are 2x2 (300mbit) or 1x1 (150mbit), you might want to consider Ruckus's 2x2 stuff (like the R500 or R300 or 7372) since you really aren't getting too much advantage out of the 7982/R700 unless you have a ridiculously dense or polluted environment.