TCP BBR impacts the WiFi performance

I just notice my WiFi download performance is very low from a local SAMBA server. The upload performance is normal.

Here is the test topology:
A(WiFi client) ---- WRT1200AC(LEDE) ------- B(Linux)

A is any WiFi client, my test client is a android phone with Termux app.
WRT1200AC and host B is connected with wired cable.
The LEDE version in WRT1200AC is 17.01.4. And the WiFi setting is 5GHz/802.11n/40MHz
B is a Linux PC with TCP_BBR enabled

  1. First, test the performance with iperf3 between A and WRT1200AC
    A ---> WRT1200AC: 50Mbps
    WRT1200AC ---> A: 80Mbps
    It's normal.

  2. Then, test the performance with iperf3 between WRT1200AC and B
    WRT1200AC --> B: 600Mbps
    B --> WRT1200AC: 600Mbps

  3. Test the performance with iperf3 between A and B
    A ---> B: 50Mbps # this is Okay
    B ---> A: around 20Mbps # it should be 80Mbps
    It seems there is a mysterious performance drop when forwarding the packet to wifi client.

I tried some old/new versions of LEDE, and switched many WiFi settings. the download throughput is always significantly lower than the upload throughput. Finally, I remember I've changed the TCP congestion algorithm to BBR on B several days ago. After changed it back to "cubic". The performance also come back:
B --> A: 80Mbps

I'm appropriate it if someone can give a explanation about this phenomenon.
BTW, a wired client in LAN side doesn't have this issue.

you have to increase packet/queue/buffer size in order to gain higher throughput. i'm experiencing similar with iperf2 and iperf-mt. with some (optimized) drivers like mt76 or binary mtk driver you get more bandwidth if running iperf with -l 4096 option, or increase window size to 320 KB. with standard configuration my tests with mtk driver reached about 130Mbps, turn on hw acceleration it goes up to 170Mbps and finally with large buffer around 200Mbps. both mt7612 and mt7620.

1 Like

Just an FYI, 5GHz is not meant to be run in legacy N mode, as that's what the 2.4GHz radio is for. 5GHz should be AC only.

Thanks. I'm not meant to gain a higher throughput. I'd like to know why the throughput is so different between TCP BBR disabled and enabled under the same test environment and the same iperf parameters.

Actually, I also tested the AC mode. The test result was no different as above. The throughput dropped significantly after enabled the TCP BBR.

It seems I find the answer from BBR development group.

"where the current upstream BBR parameters for provisioning
cwnd need to be more generous for paths like wifi LAN paths, which
have ACKs that are often delayed much longer than the minimum RTT
observed over the path"

https://groups.google.com/forum/#!searchin/bbr-dev/wifi|sort:date/bbr-dev/y-rOr6mwk-s/2-xDG5K1BwAJ
This issue will be fixed in the BBR v2.0

1 Like