RE: Low performance of BBR compared to cubic
- Reply: Scheffenegger, Richard: "Re: Low performance of BBR compared to cubic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 20 Nov 2023 12:29:30 UTC
BBR has not been looked after for quite some while (and there are no plans to invest there). Among other things, the blatant disregard of flow fairness which BBRv1 shows, makes it a poor protocol for general use. Similar issues also show up with BBRv2 (current version), but still it is not considered a reasonable and stable enough protocol - thus the IETF is working on BBRv3. Both of which would require effective re-implementation of the BBR stack. RACK is expected to perform better across congested paths, and in the presence of various pathological network issues. In particular, the receive path is certainly not as performant as the Base Stack currently. In short: If you want to use BBR, please don't use the current code with is at best a variation of BBRv1 - and it's generally known that this version of BBR is not "good". (I presume your testing was acrosss a green field / zero loss network, with ample bandwidth - maybe the loopback interface even). Richard -----Original Message----- Hi, While test TCP RACK functions, I tested BBR BTW. This is a quick test with iperf3 on bare metal ( old MBP i5 2 cores 4 threads ). The kernel current/15 with debug options disabled. Following is the performance result: freebsd: 37.2 Gbits/sec 1.32 MBytes RACK: 27.9 Gbits/sec 1.34 MBytes BBR: 2.34 Gbits/sec 223 KBytes For freebsd and RACK functions the CC is cubic. The last column is Cwnd. BBR's Cwnd looks quite small. There's also a report on Telegram Taiwan FreeBSD chat group, but without performance details. I believe there is something wrong with BBR. This is not a reasonable good performance compared with other tcp congestion control algorithms. Or am I missing something ? Best regards, Zhenlei