Summary

Question

Customer Environment

Symptoms

• Low Data Rates: Clients experience slower than expected data transfer speeds
• An internet speed test download / upload value does not match speeds seen on a wired laptop / mac

Troubleshooting Steps

This article starts with an introduction to common issues and symptoms seen on 802.11 WLANs hosted on RUCKUS which are related to throughput and speed. We discuss how MCS, MIMO and hardware specifications determine the wireless throughput. We also dive into detailed troubleshooting involved in improving and determining the cause for some throughput/speed issues seen on RUCKUS WLAN deployments.
Please note, RF issue related packet loss and latency related issues are not discussed on this document.

Introduction

Throughput issues on 802.11 networks can significantly impact the performance and user experience. This article provides a detailed guide to identifying and resolving common throughput problems on the RUCKUS networks WLAN product line.

Common Symptoms

• Low Data Rates: Clients experience slower than expected data transfer speeds
• An internet speed test download / upload value does not match speeds seen on a wired laptop / mac

Root Causes

• Interference: External RF interference from other devices can degrade throughput.
• Signal Strength: Weak or inconsistent signal strength can lead to lower data rates.
• Channel Congestion: Overlapping channels and high traffic can reduce available bandwidth.
• Client WIFI card bottlenecks and compatibility issues
• Configuration related issue

Understanding MCS/ MIMO Chains and Client specifications

To troubleshoot throughput / speed issues it is important to calculate a reference value to compare existing throughput / speed with.
The following concepts are key to understanding the theoretical rate that a client can potentially reach if underlying environment and hardware factors align.

1. Modulation and Coding Scheme (MCS) :

• The Modulation and Coding Scheme (MCS) is a key factor in determining the data rate of a wireless connection.
• MCS combines modulation (how data is encoded onto the carrier signal) and coding (error correction techniques) to define the data rate and robustness of the transmission
• Higher the negotiated MCS, higher will be the data rates / throughput.
  • On MAC OS device you can use the inbuilt WIFI Menu to find the current MCS in use, this can be invoked by

Pressing the OPTION (or ALT) key and keep it pressed while clicking the WiFi icon
Reference: WiFi icon in the Menu Bar

• On a Windows device you can calculate the MCS index using the TX and RX rates and its matching MCS index (table) using the command attached below or by using a third party tool like inSSIDer
• The general rule here is the system show show higher TX and RX rates

1. Open the Command Prompt by pressing Win + R, typing cmd, and hitting Enter.
2. Type netsh wlan show interfaces and press Enter.
3. This command will display details about your WiFi connection, including the current data rate.
4. Use an MCS Index Table:  The MCS Index Table helps you understand the quality and maximum data rate of your WiFi connection. You can find MCS tables online that list the modulation schemes and coding rates for different WiFi standards (e.g., 802.11n, 802.11ac, 802.11ax).
5. Calculate the MCS Value: Compare the data rate from the Command Prompt with the MCS Index Table. Match the data rate with the corresponding MCS value, modulation type, and channel width.

Reference: Calculating WLAN MCS on a Windows OS device

Method 2:

Figure 1: Sample output from a third party tool called inSSIDer.

On an Android and iOS devices we need third party applications to view this data:

MCS Table Basics: The MCS table and how to use it
The MCS Table: https://mcsindex.com/
 

2. MIMO Chains:

• Each MIMO WLAN Client supports mutiple spacial streams, TX, RX antenna Arrays which represented by the following notation TxR:S.
• The same applies to a Ruckus access point. The more number of spacial streams supported by the WLAN card more the throughput.
• The notation typically follows the format TxR:S, where:

T represents the number of transmit antennas.
R represents the number of receive antennas.
S represents the number of spatial streams.

Examples
2x2:2 MIMO:
2 transmit antennas
2 receive antennas
2 spatial streams

4x4:4 MIMO:
4 transmit antennas
4 receive antennas
4 spatial streams

3x2:2 MIMO:
3 transmit antennas
2 receive antennas
2 spatial streams (limited by the number of receive antennas)

• The supported spacial streams for a Ruckus AP can be found on the AP datasheet

• Supported spacial streams/antenna array information for the client can be found in client user manual or its online help resources.

MIMO Basics:  Multiple-Input Multiple-Output

3. Client specifications and considerations:

• Client WIFI card and driver versions play a significant role in WLAN throughput. Always update the client to the latest stable OS version and driver version
• For higher throughput requirements please ensure line of sight between the Ruckus Access Point and the client
• Closer you are to the Access Point, higher will be the throughput (the reverse condition is also true for MIMO and MU-MIMO clients, please ensure that the client is at least 3 - 5 feet away from a Wifi6/Wifi6E/Wifi7 AP to ensure proper MIMO stream formation)
• Most modern day applications/ software do not use more than 150 Mbps, this includes video streaming services like Netflix/ YouTube etc at max resolutions, multiple clients using max throughput can cause channel utilization issue regardless of AP/ Client specification which in turn is a performance issues.
  • Hence please consider limiting throughput/ speeds via a bandwidth restriction for dense deployments.
  • Trends seen on customer networks are as follows:
    • Guest Networks 15 Mbps up and 15 Mbps Down
    • Video streaming / Corporate Networks: 75 Mbps up and 75 Mbps down 
    • Unlimited bandwidths configuration are usually seen on datacenter networks, IT Lab networks and rooms used to re-image networking equipments, servers and clients
      • These deployments typically have low client density
• Since most traffic on an enterprise network is intended for internet access in the downlink direction (AP to Client or Internet to Client) it is a good practice to implement a per user band width contract based on applications / end user use case.

Troubleshooting Steps:

• Wired client to wired client = A
• Wireless to wired = B
• Wired to wireless = C

• Throughput in scenario A < C - the iperf test conducted is invalid
• Throughput in scenario A ~ C - network is perfect
• Throughput in scenario A > C - this is normal for most deployments
• Throughput in scenario B / C is less than 50 - 75 % of that seen in scenario A

Ruckus SmartZone Deployments:

• Ruckus Smart Zone AP's on version 6.1.2 and above have build in iPerf capabilities
  • This can be used as an alternate to a Wired client in the tests discussed above provided that the AP VLAN and Client VLAN are the same or have routing allowed between the VLANs
• Validate the client RF details by navigating to Monitor > Clients > Wireless Clients >  search for the client mac address
  • Data of interest
    • RSSI
    • SNR
    • Rx MCS Rate
    • Tx MCS Rate

• In the example shown above the client is negotiating 130 Mbps up / down on 2.4 ghz on channel 1
• If any of the values MCS / RSS or SNR is found to be degraded or below optimum try the following
  • Move the client closer to the AP
  • Change the AP channel or change the AP channel bonding configuration

• If the client RSS and SNR are optimum but the client still shows throughput miss matches between iperf tests
  • Validate the number of clients connected to the single AP and try to test throughput on a single AP single client scenario to get a base line
    • Try applying a bandwidth contract and see if the client is able to get the rates set on the bandwidth contract
  • Validate AP uplink port stats via the AP support logs and check for drops on the eth ports 
    • Wifi > AP List > Select the AP the tests were conducted on > More Actions >  Download Log
      • In the example shown below the AP is dropping packets on the ethernet interface eth0
      • The expectation for a wired interface statistics is 0 errors
      • The amount of muticast packets is also a concern as it may also reduce throughput if they are intended for the client VLAN
        • Muticast inbound can be dropped / disable via the WLAN configuration

### /proc/net/dev ###
<--- Receive Statistics --->
Interface           bytes   packets  errors      drop  FIFO   Frame   Mcast   ZIP
       bond0            0         0       0         0     0       0       0     0
         br0    225002741   2227377       0         0     0       0       0     0
        eth0   1110464486   5788054       0        34     0       0   454455     0

• Also check the AP POE status and if its supplied with the recommended power
  • R7xx, R6xx 30 W minimum via POE + (802.3at) or POE ++ (802.3bt) or PoH  

RuckusOne Deployments:

• Validate the client details by navigating to Clients > Wireless Clients List > Select the client > Troubleshooting > Connection Quality > Avg. MCS(Downlink) / RSS / SNR
• Data of interest
  • RSSI
  • SNR
  • Rx MCS Rate
  • Tx MCS Rate

• If any of the values MCS / RSS or SNR is found to be degraded or below optimum try the following
  • Move the client closer to the AP
  • Change the AP channel or change the AP channel bonding configuration

• If the client RSS and SNR are optimum but the client still shows throughput miss matches between iperf tests
  • Validate the number of clients connected to the single AP and try to test throughput on a single AP single client scenario to get a base line
    • Try applying a bandwidth contract and see if the client is able to get the rates set on the bandwidth contract
  • Validate AP uplink port stats via the AP support logs and check for drops on the eth ports 
    • Wifi > AP List > Select the AP the tests were conducted on > More Actions >  Download Log
      • In the example shown below the AP is dropping packets on the ethernet interface eth0
      • The expectation for a wired interface statistics is 0 errors
      • The amount of muticast packets is also a concern as it may also reduce throughput if they are intended for the client VLAN
        • Muticast inbound can be dropped / disable via the WLAN configuration

### /proc/net/dev ###
<--- Receive Statistics --->
Interface           bytes   packets  errors      drop  FIFO   Frame   Mcast   ZIP
       bond0            0         0       0         0     0       0       0     0
         br0    225002741   2227377       0         0     0       0       0     0
        eth0   1110464486   5788054       0        34     0       0   454455     0

• Also check the AP POE status and if its supplied with the recommended power
  • R7xx, R6xx 30 W minimum via POE + (802.3at) or POE ++ (802.3bt) or PoH  

Ruckus Unleashed Deployments/ Zone Director deployments:

• Validate the client RF details by navigating to  Clients > Select the client of interest > Show Details
  • Data of interest
    • RSSI
    • SNR
    • Rx MCS Rate
    • Tx MCS Rate

• In the above example a client with an RSSI of -51dBm and an SNR of 45 dB is able to maintain 960 Mbps
• If any of the values MCS / RSS or SNR is found to be degraded or below optimum try the following
  • Move the client closer to the AP
  • Change the AP channel or change the AP channel bonding configuration

• If the client RSS and SNR are optimum but the client still shows throughput miss matches between iperf tests
  • Validate the number of clients connected to the single AP and try to test throughput on a single AP single client scenario to get a base line
    • Try applying a bandwidth contract and see if the client is able to get the rates set on the bandwidth contract
  • Validate AP uplink port stats via the AP support logs and check for drops on the eth ports 
    • Access Points > System Default > AP >

• In the example shown below the AP is dropping packets on the ethernet interface eth0
  • The expectation for a wired interface statistics is 0 errors
  • The amount of muticast packets is also a concern as it may also reduce throughput if they are intended for the client VLAN
    • Muticast inbound can be dropped / disable via the WLAN configuration

### /proc/net/dev ###
<--- Receive Statistics --->
Interface           bytes   packets  errors      drop  FIFO   Frame   Mcast   ZIP
       bond0            0         0       0         0     0       0       0     0
         br0    225002741   2227377       0         0     0       0       0     0
        eth0   1110464486   5788054       0        34     0       0   454455     0

• Also check the AP POE status and if its supplied with the recommended power
  • R7xx, R6xx 30 W minimum via POE + (802.3at) or POE ++ (802.3bt) or PoH