A Simple BBR Test on Linode
Overview:
TCP BBR solves two problems:
- Fully utilizing bandwidth on network links with some packet loss. Suitable for high-latency, high-bandwidth network links.
- Reducing buffer occupancy on network links, thereby lowering latency. Suitable for users with slow access networks.
I remember when BBR was first merged into the Linux 4.9 kernel in 2017, this congestion control algorithm proposed by Google was extremely popular in the tech community. At the time, I was doing cross-border file transfers on Linode, where packet loss was commonplace, so I wanted to test the results firsthand.
Test purpose: This test primarily focuses on packet loss rates. For more convincing tests, please refer to Lawrence Brakmo’s BBR Report. The Other Side of BBR
Test Setup:
- ADDR01: aaa.aaa.aaa.aaa
| |
- ADDR02: bbb.bbb.bbb.bbb
| |
These two Linode machines were in different data centers — one on the US West Coast and one in Europe — simulating a cross-border network environment. At the time, CentOS 7 still used the 4.4 kernel by default, while BBR requires Linux 4.9+, so upgrading the kernel was necessary before enabling BBR.
Test Method:
- Simulated packet loss scenarios from 1% to 30%, testing different kernels with and without BBR enabled.
Linux’s traffic control tool tc can simulate various network conditions through netem, including packet loss, latency, jitter, etc. This is the standard tool for network testing. rsync was chosen as the testing tool because the real-world use case is cross-server file synchronization, which is closest to actual usage.
tc commands used:
| |
- Test transferring data from ADDR02 to ADDR01. ADDR01’s kernel remained unchanged, while ADDR02’s kernel was adjusted and rebooted for each test.
Test Process:
- Steps omitted. test.gz is approximately 160MB, a compressed package normally used for backing up code. The general process was as follows:
Without BBR enabled, transferring data from ADDR02 to ADDR01:
| |
During the transfer, the difference was very noticeable. Without BBR, the speed fluctuated — at 3.27MB/s, you could clearly see the progress bar moving slowly. Waiting for the 160MB to finish felt like a long time.
Test Data Comparison:
| 4.8.6-x86_64-linode78 | 4.9.15-x86_64-linode78 | Non-linode official 4.10 kernel (generic) | |
|---|---|---|---|
| Without BBR, normal conditions | 3.27MB/s | 3.36MB/s | Not tested |
| With BBR, normal conditions | Not tested | 3.45MB/s | 2.31MB/s |
| With BBR, 1% packet loss | 3.19MB/s | Not tested | Not tested |
| With BBR, 10% packet loss | Not tested | 3.21MB/s | 2.81MB/s |
| With BBR, 30% packet loss | 97.30kB/s (last result before interrupting after 20 minutes without completing transfer) | 1.35MB/s | 1.15MB/s |
Test Summary and Observations (based on the above results):
- Linode’s custom-compiled kernel has noticeable targeted optimizations with significant effects.
- With BBR enabled, transfers could still complete even with 30% packet loss, demonstrating BBR’s effectiveness.
- The 4.10 kernel used generic instead of lowlatency.
- Originally planned to test 50% packet loss as well. However, after setting 50%, remote access to ADDR01 became nearly impossible, so the test was abandoned. At 50% packet loss, even SSH connections started lagging, making remote operations basically impossible, so this test had to be scrapped.
Appendix:
- CentOS 7 official kernel upgrade method:
This was the standard method for upgrading CentOS 7 to the 4.x kernel at the time, getting the latest ml (mainline) kernel through the elrepo repository:
- Upgrade kernel:
| |
- Update boot:
| |
- Enable BBR:
| |