BBR on a 1 GB VPS: the buffer settings matter more than the algorithm
Every tuning guide for a small VPS starts the same way: enable BBR, reboot, declare victory. On our test instance — one vCPU, 1 GB of memory, a trans-Pacific path of roughly 105 ms — the algorithm change alone moved single-flow throughput by less than five percent. The ceiling was somewhere else entirely.
The actual bottleneck: buffer ceilings from another era
The stock configuration capped the maximum receive and send socket buffers at about 208 KB. The arithmetic is unforgiving: a flow can have at most one buffer of unacknowledged data in flight, so throughput is bounded by buffer size divided by round-trip time. 208 KB over a 105 ms path tops out near 16 Mbps no matter what the congestion controller decides. The defaults were sized for datacenter LANs with sub-millisecond latency, and they silently cap every long-haul flow.
Sizing from the bandwidth-delay product instead: a 500 Mbps path at 105 ms needs roughly 6.5 MB in flight. We set the buffer ceilings to 16 MB with a 1 MB default, which leaves headroom without letting a single socket pin a meaningful share of a 1 GB machine.
Pairing BBR with the right qdisc
BBR paces its packets and expects the queue discipline underneath to cooperate. The distribution default had written fq into the sysctl configuration while the interface was in fact still running fq_codel — a reminder to always read the live qdisc off the interface instead of trusting the config file. Setting the interface to fq, and raising the initial congestion window on the default route, removed the slow ramp that had been taxing every short transfer.
Measurement, not vibes
Three transfer patterns, before and after, against a peer 105 ms away: a short-haul reference path (about 12 ms) was used to confirm the machine itself could push over 700 Mbps cleanly, so any remaining ceiling was path or configuration, not CPU. On the long path, single-flow upload rose from about 207 Mbps to about 378 Mbps with zero retransmissions. Download stayed near 175 Mbps in both configurations — the sending peer was the limit there, and no client-side knob changes that.
Multi-flow tests told a subtler story: pushing four streams raised aggregate throughput but with retransmission rates of several percent on the shared trans-Pacific path. Capping the aggregate rate did not eliminate the loss, so we declined to add traffic shaping. A hard limit tuned to the wrong bottleneck only taxes the paths that were already clean.
The takeaway
On small instances, the order of operations matters: measure the path, size the buffers from the bandwidth-delay product, verify the qdisc that is actually running, and only then judge the congestion control algorithm. BBR is a good default. It is just not the first place the performance was hiding.