Speedtest wires vs wireless - interpret results

Hardware Questions and Recommendations
1

To test the max throughput of my wirelss connection I´ve setup iperf3 locally, and run this command:

iperf3.exe -c <iperf-server> -i 1 -t 30 -w 4M -P 10 -O 3
  -i, --interval  #         seconds between periodic bandwidth reports
  -t, --time      #         time in seconds to transmit for (default 10 secs)
  -P, --parallel  #         number of parallel client streams to run
  -w, --window    #[KMG]    set window size / socket buffer size
  -O, --omit N              omit the first n seconds

.. Gives me this result:

[SUM]   0.00-29.99  sec  1.10 GBytes   315 Mbits/sec                  sender
[SUM]   0.00-29.99  sec  1.10 GBytes   315 Mbits/sec                  receiver

Running speedtest-cli on the wireless client gives me this result

Download: 74.77 Mbit/s
Upload: 155.99 Mbit/s

However, running speedtest-cli on a wired connection gives me this:

Download: 215.59 Mbit/s
Upload: 222.86 Mbit/s

Obviously, the throughput to the speedtest server (same used in wireless and wired test) can handle 200+ mbit in both directions - as shown by the wired speedtest. But why does the wireless speedtest, especially the upload differ so much compared to the wired one? Is it related to the increased latency using wifi? Simply less time to transmit data?

General question, how does the number streams supported by access-point and client relate to speedtest with or without multi connection?

Hardware:

  • Wireless client: Lenovo T470 w/ Intel Dual-Band Wireless-AC 8265 (2x2, 2.4 & 5 GHz) with a maximum transfer rate of 867 Mbps.
  • Access point: TP-Link EAP330

Kind regards, Erik

2

There are likely a couple of reasons for this.

Firstly, wireless clients, especially phones, often have asymmetric downlink/uplink speeds due to design criteria related to the antennae and the power available which leads them to be slower on upload. The AP can also form nice beams to the client, whereas the inverse is not always true.

When wireless clients are downloading, the AP is scheduling the packets and it does not have any contention on the media access layer from other devices. When uploading, the wireless clients DO contend for access, which in itself creates a delay and can also adjust the tcp window, resulting in lower upload speeds.

Then, the options you use on the client make a difference. CPU bounding can make a big difference on devices with less horsepower, such as phones. For example, using the -Z flag on iperf3 on my android device makes a significant difference to throughput.

Likewise, ignoring the the first, say 10 seconds, with the -O 10 flag also makes a difference as tcp gets off to a slow start. Then time it for a longer period with something like -t 20 and reverse the flow with -R so that the server sends the data to the client (downlink) rather than the client sending the data to the server (uplink).

So, something like the following. I bet you'll see the performance improve.

iperf3.exe -c <iperf-server> -t 20 -O 10 -Z -R
2 Likes
3

Thanks for the reply! Need to fix linux to run the command though:

"iperf3: parameter error - this OS does not support sendfile"

4

Linux doesn't support -Z parameter. Android does, and I think Windows 10 does too