Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the updraftplus domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /data/wwwroot/wordpress/wp-includes/functions.php on line 6121
Understanding WiFi Throughput: Testing Methods and Tools with iPerf - Ax3soft

Understanding WiFi Throughput: Testing Methods and Tools with iPerf

1. Introduction to Throughput

1. Uplink WiFi throughput testing method: The phone functions as the client, while the PC serves as the server. 2. Downlink WiFi throughput testing method: The phone serves as the server, and the PC acts as the client.

What is WiFi throughput? Data in a network is composed of data packets, and processing each packet by a firewall consumes resources. Throughput refers to the maximum rate a device can handle without frame loss. It can also be defined as the amount of data passing through a network or interface within a unit time, including all upload and download traffic.

Tool for testing throughput: iPerf iPerf is a cross-platform network performance testing tool that supports Win/Linux/Mac/Android/iOS platforms. iPerf can test TCP and UDP bandwidth quality and measure the maximum TCP bandwidth, featuring various parameters and UDP characteristics. iPerf can report bandwidth, delay jitter, and packet loss. Using this feature, it can test the performance of some network devices such as routers, firewalls, switches, etc.

-s Start in server mode, e.g.: iperf -s -c host Start in client mode, where host is the server end address, e.g.: iperf -c 222.35.11.23 -f [k|m|K|M] Represent report in Kbits, Mbits, KBytes, MBytes respectively, default in Mbits, e.g.: iperf -c 222.35.11.23 -f K -i sec Display report interval in seconds, e.g.: iperf -c 222.35.11.23 -i 2 -l Buffer size, default is 8KB, e.g.: iperf -c 222.35.11.23 -l 16 -m Display maximum TCP MTU value -o Output reports and error information to file, e.g.: iperf -c 222.35.11.23 -o c:\iperflog.txt -p Specify the port used by the server or the port connected by the client, e.g.: iperf -s -p 9999; iperf -c 222.35.11.23 -p 9999 -u Use UDP protocol -w Specify TCP window size, default is 8KB -B Bind a host address or interface (used when the host has multiple addresses or interfaces) -C Compatibility with old versions (used when server and client versions are different) -M Set maximum TCP packet MTU value -N Set TCP no delay -V Transmit IPv6 packets server specific parameters -D Run iPerf as a service, e.g.: iperf -s -D -R Stop iPerf service, for -D, e.g.: iperf -s -R Client specific parameters -d Simultaneous bidirectional transmission test -n Specify number of bytes to transmit, e.g.: iperf -c 222.35.11.23 -n 100000 -r Separate bidirectional transmission test -t Test time, default 10 seconds, e.g.: iperf -c 222.35.11.23 -t 5 -F Specify the file to be transmitted -T Specify TTL value

2. Factors Affecting WiFi Throughput

Firstly, throughput is an extreme test, which examines the maximum network capacity of a phone under extreme conditions. Therefore, it is best to test in a nearby shielded room environment to eliminate interference. 1. Software factors Background scanning Bluetooth coexistence EDCA contention, RTS, CTS frames, etc. Screen-off power-saving mode 2. Hardware Transmitter: transmission power, spurious emissions, etc. Receiver: reception sensitivity, multiple antenna reception differences, board interference, etc. 3. Environmental factors Co-channel interference Adjacent channel interference Low-speed device NAV 4. Other system performance CPU scheduling Background manager control Application sensitivity

3. Analysis Method

Direct cause: The direct cause at the WiFi level is that the rate negotiation fails or cannot recover quickly after speed drops due to packet retransmission. Analyzing the root cause should be based on the direct cause. Software firmware, hardware radio frequency, and antennas may cause rate negotiation failure, fast speed drop, and prolonged recovery from a speed drop. 1. First, confirm the TCP port flow Directly open Wireshark, filter TCP data flow from tcpdump or air interface logs. This step is relatively easy because throughput testing is generally an extreme test, and no other applications will be running in the background. Using magic iPerf, the server port is generally fixed at 5001, making it easy to find the corresponding long TCP connection. 2. Wireshark filters air interface TCP data flow Use Wireshark filter rule: tcp.port eq 5001 && ip.dst eq [] can filter out related flows 3. Wireshark IO statistics WiFi rate changes Set the y-axis to wlan_radio.data_rate to view physical layer rate changes of the TCP flow.

4. Analysis from Transmission and Reception

1. Sending, filter wlan.sa eq [] Wireshark’s IO statistics of WiFi retransmission packets—because retransmission is the direct cause of speed drops Set the y-axis to wlan.fc.retry to view physical layer rate changes of the TCP flow. Wireshark’s IO transmit power Set the y-axis to wlan_radio.signal_dbm 2. Reception part Check each chain’s RSSI in the driver log wlan: [931:D:HDD] hdd_wlan_fill_per_chain_rssi_stats: 4316: RSSI for chain 0, vdev_id 0 is -54 wlan: [931:D:HDD] hdd_wlan_fill_per_chain_rssi_stats: 4316: RSSI for chain 1, vdev_id 0 is -68 Check packet error situation in the FW log R0: FWMSG: [14a30036bc5] ANI_DBGID_POLL phyId 0 listen_time 61-61 ofdmPhyErrCnt 10 cckPhyErrCnt 3 ofdmPhyErrRate 163 cckPhyErrRate 49 level 2 4. Comprehensive analysis based on results 1. If there are many transmission retransmissions, generally it is a radio frequency or antenna issue Check TRP index, if there is no issue, consider antenna impedance or radio frequency board interference. 2. If transmission retransmissions are few, consider software-side firmware issues 3. If there are many reception packet errors, generally it is also a radio frequency or antenna issue Check TSI index, if there is no problem. Consider significant signal strength differences among multiple antennas such as chain1; you can check related RSSI in the driver log. 4. If the reception packet error rate is consistent, consider software-side firmware issues.