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
First, test the performance with iperf3 between A and WRT1200AC
A ---> WRT1200AC: 50Mbps
WRT1200AC ---> A: 80Mbps
It's normal.
Then, test the performance with iperf3 between WRT1200AC and B
WRT1200AC --> B: 600Mbps
B --> WRT1200AC: 600Mbps
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.
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.
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"