How to debug WLAN throughput?
Tags : wlan throughput
♠ There are many parameters involved when we debug throughput. Less throughput may be due to software bug or set up changes or environment etc.
Let’s have a look into below points and their corresponding reasons or descriptions.
Note: It’s assumed that throughput set up is inside big or small RF chamber . Set up may be cabled or open air inside RF chamber.
| SL | Check Point | Reason/Description |
| 1. | Windows Iperf version | I have observed that windows iperf 2.0.5win32 has some data pumping issue while running 11ac throughput, where iperf 2.0.9 is good. Do not know the reason, but I have faced this. |
| 2. | DUT link speed | While running throughput, check for DUT link speed using “iw wlan0 link” command to see if it is fluctuating. To get best throughput, link should be highest data rate of the connection. Example: Connection :: ExpectedLinkSpeed 11ac 2×2 SGI 80MHz :: 866.6Mbps 11n 1X1 SGI 20MHz :: 72.2Mbps |
| 3. | Less Iperf pumping | Check iperf pumping data rate for each iperf interval. If it’s not pumping enough then use multiple streams [-P <number of stream> or this may be DUT software bug]. |
| 4. | Ixia chariot script issue | If you are using ixia chariot for measuring throughput then use default standard scripts for TCP and UDP. Generally we do not have to change anything for TCP scripts but UDP scripts may need some modifications. TCP default script is : High-Performance-Throughput.scr UDP default script is : UDPThroughput.scr You may need to use multiple pairs to pump enough data. |
| 5. | AP backend pumping | We need to check for AP backend pumping also. Try to connect AP backend to the inbuilt LAN of system instead of using USB-to-ETH. Even if USB-to-ETH says 1Gbps but pumping may be less [Observed 350Mbps] and this leads to low throughput. |
| 6. | iw wlan0 link | DUT link speed should show the connection maximum physical data rate. Example: If STA supports 11n 1×1 2.4GHz 20MHz SGI, then STA link speed should be 72.2Mbps. We can use command like “iw wlan0 link”. Here we can observe for good RSSI also. Though there is no fixed optimal RRSI for through but range for -30dBm to -45dBm is considered as good RSSI. You may get best throughput on -5dBm alsoJ, where -5dBm is very strong signal [Observed in cabled set up].But getting good throughput on -80dBm is miracleJ. |
| 7. | Iperf window size | Try to use windows size parameter to minimum 2M [-w 2M] for TCP/UDP for bother client and server. This parameter has some effect when device an android. Also check if windows size is applied correctly or not. Try to give same windows on both server and client. Remember that there is a chance of doubling the window size provided by user in iperf argument, where in windows it’s not the case. Check below output for Android phones. root@falcon_umtsds:/ # iperf -s -i1 ———————————————————— Server listening on TCP port 5001 TCP window size: 256 KByte (default) ———————————————————— root@falcon_umtsds:/ # iperf -s -i1 -w2M ———————————————————— Server listening on TCP port 5001 TCP window size: 4.00 MByte (WARNING: requested 2.00 MByte) ———————————————————— |
| 8. | Number of MPDU within A-MPDU | From throughput capture we can check the number of MPDU within a A-MPDU. If number of MPDU is less then throughput will be less. |
| 9. | RTS-CTS | In generally there should not be any RTS-CTS exchanges while throughput is running. This reduces throughput. But some vendor implementation has by default enabled RTS-CTS before sending A-MPDU on air. Confirm this with developer. |
| 10. | Using Beamforming? | It is observed that UL throughput is lesser than DL due to third party AP uses bemaforming while sending down link traffic where this capability (beamforming) is not there for STA . Note that: TxBF does not use to increase throughput, it uses for reliability of data for far distance clients. But who knows how it helps to get some more Mbps to throughput. |
| 11. | TCP ACK | If the throughput is for TCP then TCP ACK will be seen in air. Generally these TCP ACK also come within A-MPDU. Check the same and also watch out for the data rate used to send TCP ACK. This data rate should be highest data rate of the current connection. |
| 12. | Wrong WLAN Firmware | Sometime using wrong FW results into bad throughput. Suppose the device is 2×2 [MIMO] but used FW is 1×1 [SISO]. In this case SISO FW does not have tuned RF calibration and you may see weak RSSI, retransmission, low data rate etc. Other than these we may see everything is fine. Very difficult to catchJ. |
| 13. | Android Wi-Fi scan page is opened | If STA is an android device then through may fluctuate if Wi-Fi scan GUI panel is opened while throughput is going on. Because if this panel is kept open, STA will do background scan which leads to lower average throughput. |
| 14. | STBC on/off | Generally there is no throughput differences if STBC of on or off. But STBC is on indicates AP RSSI is weak which enables the STBC Tx to increase the reliability of data. |
| 15. | Data rate | All throughput data packets should go with highest physical data rate of the current connection. If data rate is less then throughput will be less. |
| 16. | AP Backend Linux or Windows? | Ideally this should not matter but AP backend as Linux is far better than Windows. Linux is more flexible and easy to use but windows has many factor like windows iperf version, iperf window size restriction , UDP pumping etc. |
| 17. | Device orientation/ Position | If the throughput set up open air within RF chamber then orientation/position matters. Especially for SISO line of site [LOS] is best to get maximum throughput. If possible throughput set up can be RF cabled inside RF chamber. |
| 18. | Windows Iperf multiple pairs for UDP server | If we want to run multiple pairs/streams for UDP and the iperf server is in windows, then we do not see multiple steams are working on UDP server at windows. It’s a known issue. Nor sure if this has any fix in windows. |
| 19. | Bandwidth -b? | We use -b option for UDP iperf data pumping. In generally -b value should be the maximum expected link speed. But we can also use some more than that. Example: If link speed is 72.2Mbos then -b can be 72Mbps. Giving huge value for -b doed not make much sense. But some time to increase pumping we can use multiple stream option “P”. This helps to get good throughput for small CPU or low end Android phones. Example: -b 100M with -P2 means total pumping of 100×2=200Mbps. |
| 20. | DL > UL | It’s observed that DL STA throughput is more than UL STA throughput. The reasons are 1. More Tx Power 2. More buffer size [That’s why we see more MPDU inside A-MPDU for DL Data] 3. More antenna [Can use Tx Beamforming if required] 4. High quality Wi-Fi chip is used inside AP. Example: BRCM chip. |
| 21. | Increase stream or pair | DUT is STA with link speed 433.3Mbps [11ac 1×1 80MHz] Command :: Throughput -b 500M -P1 :: 250Mbps -b 500M -P2 :: 370Mbps Why? This may happen for small CPU like low end android phone. |
| 22. | Debug log enabled | Sometime throughput will be less because debug log level is high or more development log is enabled. If we disable logs, we may get expected throughput number. It’s recommended that no debug build should be used for executing throughput. |
| 23. | Operating Mode Notification | Suppose STA supports 11ac 2×2 (866.6Mbps) but we are seeing 1×1 data rate (433.3Mbps) for data frames after association. Why? There may be a chance for STA sharing “Operating Mode Notification” in Association Request to operate in 1×1 even though AP and STA both supports 2×2. |
♠ Conclusion:
We have just shared few points about debugging Wi-Fi throughput issue. There may be more. You can share your observation in comment sections.