Wireless speed is not expected? Get to know about TCP BBR!

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.