Wireless Access

I'm having an issue with low goodput numbers at an office locatioin. The office is setup with two 3400 Series Mobility Controllers with several Aruba AP225 connected. Both the controllers and APs are connected to dedicated switches and isolated from wired users.

 

Controllers are running OS version 6.4.1.0 and average 250 to 450 clients daily.

 

Most of the clients are connected at 5Ghz band with ac Radio/Client PHY 80 Mhz and Radio 80 Mhz/ Client 40Mhz.

 

I've noticed that several client workstations show very low Goodput numbers. I believe the issue is related to a driver issue with the workstation. But, I want to confirm that a config on the controller isn't causing the issue.

 

I have several other controllers in the field with the same configs. None of the others appear to be experiencing the same low goodput from client workstations.

 

Any suggestions/advice for possible root causes for issue? mobility controller configuration? workstation Wireless NIC driver?

#AP225
#3400

Have you made a correlation with AP location and the location of the clients? Could they at the edge of the cell?

 

Low Goodput = < 24 Mb data rate 

 

 

 

Thanks for the response. The only factor that seems to be contributing to the low goodput is the frame types..specifically the conversion process.

 

The 3400 controller w/ AP225s is not converting bcast and mcast frame types into unicast correctly. I have 4 other controllers installed in different offices. The same workstations are used at all 4 offices. None of the other sites are experiencing the same issue.

 

I checked and verified: Convert Broadcast ARP request to unicast is enabled. Drop Broadcast and Unknown Multicast is not selected on each controller.  

 

 

#AP225

anthony.i.brice,

 

That "low goodput" number could be due to contention (the presence of other devices).  Both of those screenshots show less than 2% of the traffic to the client is dropped, which is typically very good.

I agree. The less than 2% is a good number. Our environment exists of two main wireless NIC: Broadcom 11a and Intel Dual Band AC 7260.

 

However, if you look at the Channel Busy % , the site with AP225 posts Channel Busy % above 50% consistently, which triggers massive fluatuations in speed. Basically, the speed drops from 866Mbps to 720Mbps to 124Mbps to 24Mbps in less than 2 minutes. No movement in laptop position. Client SNR is 45db. Laptop is connected to the same AP..no roaming. 

 

In contrast, the site with AP135s post Channel Busy %'s below 20%. The speed of the same client machine remains 300Mbps. No fluatations in speed with the addition of more applications or Lync usage.

#AP225

You could try using 40 or even 20 MHz channels in those locations to improve that. It requires almost ideal conditions and short distance to maintain 866 or even 720. It is not as hard to achieve 300, so the speed might be a little misleading.

Is channel busy across all channels in the 5ghz?

The Channel Busy appears to be evenly distributed across the 80Mhz Channels 149, 161, 153,157.

 

I noticed that the AP Regulatory Domain default profile did not have a channel group selected. It was listed as N/A. 

 

So, I set the Valid 802.11a 80Mhz Channel Group to 149-161.

You should revert (change back) your settings in the regulatory domain profile, because those do not control the width of your channels directly.

 

To change from 80 mhz to 40 mhz, you should change the under the 5ghz radio, you should change the ARM profile.  Uncheck 80 mhz support and leave "allowed bands" as a-only:

 

 

To change to 20 mhz channels, in your ARM profile under the 5ghz radio, Uncheck 80 mhz support and make "Allowed Bands" None:

 

Thanks for the suggestions. I'll revert the regulatory domain profile back to the default.

 

I already have Allowed Bands for 40Mhz Channels set to "A-only". However, I see that 80Mhz Support was enabled. I'll deselect the 80Mhz Support option in the ARM Profile.

 

Thanks for the suggestion. I'll give that a try.

Finished with the config changes. I did see a decrease in the Channel Busy % on 5Ghz Band. So far, the speeds seems to have settle down and remain consistent on both 11n and 11ac client test workstations.

 

Also, I've seen a much improved Goodput numbers. Much more frame types are falling into Ucast then before.

 

However, I did notice that the max speed of the 11ac client has changed from 866Mbps to 400Mbps, which is probably a result of disabling 80Mhz Support on the RF Profile. What are your suggestions on how to maintain the availability and benefits of 80Mhz and allow the 11ac clients the capability of leveraging the higher speeds?

- I am not sure how channel busy is reported when channels are bonded.  It is possible that reading is not representative of all channels when reporting more than a single channel together.

- Theoretical achievable data rates are based on how many channels are bonded, the capability of the client and the capability of the access points.  Please see the rate charts here:  http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/TUTORIAL-ArubaOS-6-3-and-Above-802-11ac-Enable-VHT-even-if-you/m-p/142739

- Actual rates depend on distance, contention with other clients and potential interference in the space.  Many of the higher rates are heavily dependent on close distances to the access points.  As clients get further away from access points, their negotiated rates go down, as it becomes more difficult to send packets successfully at higher rates.  Other clients that may or may not support 80mhz or even 40 mhz channels also consume part of the medium and could make an 802.11ac client de-rate if it cannot gain access to the medium in a specific amount of time.  Non-802.11 Interference can also cause a client to de-rate, due to the fact that transmissions are unable to complete the first, second or third time successfully.  In general, it takes more time and effort for a client to increase its rates, after de-rating that it does to de-rate.

- If you have mixed clients (AC and non-AC) and density, it is sometimes advisable to start with 20mhz channels because (1) It is the lowest common denominator for all clients (2) You have more available channels, so the likelihood of access points with overlapping channels next to each other is decreased (3) localized interference could potentially be avoided or worked around (4) 802.11ac clients will still be able to transmit at higher rates, even with 20mhz channels (4) In a mixed environment, it is statistically more likely to be able to transmit successfully at range with 20mhz channels.

 

*Everything mentioned above is theory geared towards deployment strategy assuming that most client deployments will be mixed and somewhat dense.  It is also fairly conservative.   There is nothing wrong with tuning things to get better results, because every deployment is different.

Thanks again for the info. And I totally agree with your point regarding tuning. I know the capabilities of the Aruba Ap225s. I'm certain that with more tuning, I can improve overall performance from 11ac and 11n clients connected to the AP225s. 

 

I'll follow-up with the Aruba TAC regarding Bonded Channels. There is still something not 100% right with the Ap225s and the very low Goodput %s 'From Client' compared to 'To Client' reported in the dashboard. Although, I'm getting different numbers when I pull up To/From Client Stats. Plus, I'm starting to see an increase in dropped frames to the client, which could be related.

#AP225

Thanks again CJoseph for the recommendations and advice! 

Your problems very much sounds like the environment suffers from alot of co-channel contention. Evaluate that using 80mhz channels only leaves you 4 non overlapping channels to play with.

 

If you´re using dynamic channels with ARM, In the controller you can use "show ap active" to verify the spread of channels and choise of power levels

 

Also try "show ap arm neighbors ap-name" to get a feel of how good the APs can hear eachother (through walls and floors). I´ve seen many environments with so much leakage that the only sensible thing is to use 20mhz channels and shut down alot of 2,4ghz radios. (I usually put mode-aware on and limit the 2,4ghz radio to 9-12dBm.)