Wireless speed is not expected?

Released On: 2022-07-20 06:47:07Last update time: 2022-07-25 09:46:14

Assuming there is a 1Gbps download/upload broadband connection from ISP,  a PC with 1Gbps wired capability and AX200/AX201/AX210/AX211 Wi-Fi 6 wireless network adapter has gone through the following tests:

Modem---PC, using speedtest by ookla app, there are 940Mbps download and 940Mbps upload.

Modem---Deco X90---PC, we got 940Mbps download and 940Mbps upload as well.

Modem---Deco X90 )))((( PC, however, when the PC is connected by wireless, download was only 300-400Mbps, upload was still fine, 900Mbps+.

 

Has the Deco been misconfigured?

Then We did the following comparison test to check what might be the problem.

Modem---Deco---Switch---PC1, and PC2 is connected to Deco by wireless.

We used iperf3 to run a local test, running traffic from PC1 to PC2, from which we were able to see the wireless performance between the Deco and the PC2.

Download was 940Mbps+, upload was 940Mbps+, which means there isn’t any bottleneck on the wireless part.

 

So how did this issue happen?

We performed another test in our lab with the following testing topology:

Our self-built Speedtest Server---Deco X90 )))((( PC (wireless)

On the self-built speedtest server, we used some tools to set a certain packet loss rate, which helped us reproduce the above phenomenon, here are the results:

With no packet loss set on the Server side: download 947Mbps, and upload 939Mbps.

With a 0.5% packet loss rate set on the Server side: download 646Mbps, upload 937Mbps.

As you can see, even though the packet loss rate is not huge, there is a great performance difference.

However, with a little bit of adjustment on the Server, changing the TCP congestion protocol on the server from the default cubic into TCP BBR, we have good results again, the comparison is listed in this table:

Comparison between cubic and BBR No packet loss set on Server side Set 0.5% packet loss rate on Server side Set 1% packet loss rate on Server side Set 2% packet loss rate on Server side
Using cubic on Server Download 947.085 646.134 367.123 257.489
Upload 939.225 937.729 939.623 941.526
Using TCP BBR on Server Download 935.882 911.03 921.12 931.423
Upload 943.383 945.359 944.412 955.186

 

Furthermore, in order to verify the above conclusion, we did another test in an actual environment, with actual home broadband in Singapore, using the same method as above.

Amazon AWS virtual machine running a public speedtest server --- Internet --- Home broadband --- Deco X90 --- PC1(Wired) and PC2 (Wireless)

Comparison between cubic and BBR in an actual home broadband environment PC1 (Wired) PC2 (Wireless)
Using cubic on Server Download 925.1Mbps 560.8Mbps
Upload 910.8Mbps 912.7Mbps
Using TCP BBR on Server Download 941.0Mbps 971.1Mbps
Upload 906.7Mbps 916.6Mbps

 

 

Then here comes a question: What is TCP BBR?

TCP BBR is a congestion-based congestion control algorithm developed by Google and published in late 2016. In contrast to traditional algorithms like CUBIC which rely on loss as an indicator for congestion, BBR periodically estimates the available bandwidth and minimal round-trip time (RTT). In theory, it can operate at the maximum delivery rate with minimal congestion. This prevents the creation of queues, keeping the delay minimal. BBR has been available for Linux TCP since Linux Kernel 4.9.

Since the default algorithm CUBIC is loss-based, it could be significantly affected by any packet loss, which affects the performance as well. As we all know, packet loss could happen anywhere, anytime, and it is unpredictable.

Under certain environments, when using a specific speedtest server that uses Congestion Control Protocols based on packet loss, wireless download speed might be limited, but upload won’t be affected. However, if the server uses TCP BBR instead, wireless download is significantly improved!

 

In this way, there are some suggestions when you noticed the wireless speed from Deco is slow:

If you run into issues like this, please try:

  1. Compare the results between wired and wireless, only wireless testing is having issues, wired is not affected or less affected.
  2. Run a local speedtest using iperf3 (or other custom speed test tools) to verify if the wireless part is the bottleneck.
  3. If the wireless part is not the bottleneck, you will have to seek a good speedtest server with TCP BBR enabled.
  4. Unfortunately, we cannot directly obtain the information regarding a specific server, so you may use the speedtest by ookla app and try different servers near you, we are sure that you will find a suitable one for your broadband.

 

Still having issues? Please collect the above information, especially the comparison results and the speedtest server name, and contact us.

3
Comment

Ggggff

upload
    upload