{"id":1245,"date":"2026-09-28T22:35:04","date_gmt":"2026-09-28T22:35:04","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1245"},"modified":"2026-09-28T22:35:04","modified_gmt":"2026-09-28T22:35:04","slug":"tcp-bbr-vs-cubic-vps-delivery-rate-tcp-info","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/tcp-bbr-vs-cubic-vps-delivery-rate-tcp-info\/","title":{"rendered":"TCP BBR vs CUBIC on a VPS WAN Link: What grep bw = (delivery_rate) Actually Tells You"},"content":{"rendered":"\n

Comparing congestion control algorithms by download speed alone is how you end up with a tuning change that helps one flow shape and hurts another. The kernel exposes a far better measurement: tcp_info<\/code> fields readable through ss -i<\/code>, including the delivery rate the sender itself estimates. Compare BBR and CUBIC using those fields and the reason for the difference becomes visible rather than anecdotal.<\/p>\n\n\n\n

Enable BBR correctly and verify it<\/h2>\n\n\n\n

BBR needs both the congestion control module and fair queueing on the egress path. Setting the sysctl without an fq qdisc leaves tcp_congestion_control<\/code> reported as bbr while pacing falls back to the default behaviour, which is the most common cause of “BBR did nothing” reports.<\/p>\n\n\n\n

modprobe tcp_bbr\nsysctl net.ipv4.tcp_congestion_control=bbr\nsysctl net.core.default_qdisc=fq\nsysctl -w net.ipv4.tcp_available_congestion_control\n# net.ipv4.tcp_available_congestion_control = reno cubic bbr\nsysctl -w net.ipv4.tcp_congestion_control\nip route show default\n# confirm the qdisc actually attached\nip -s link show dev eth0 | head -5\ntc qdisc show dev eth0<\/code><\/pre>\n\n\n\n
Persist with \/etc\/sysctl.d\/99-bbr.conf<\/code> and load the module at boot via \/etc\/modules-load.d\/bbr.conf<\/code>. Verify after a reboot rather than assuming.<\/p>\n\n\n\n
Read the right tcp_info fields<\/h2>\n\n\n\n
Run a transfer and inspect the socket while it is live. ss -tin<\/code> prints a set of fields that are the actual evidence:<\/p>\n\n\n\n
ss -tin state established '( dport = :443 or sport = :443 )' | head -20\n\n# fields to compare:\n#   rtt:X\/Y   smoothed rtt \/ rtt variance, microseconds\n#   cwnd:N    congestion window in segments\n#   send Zbps  application-limited send rate\n#   bw = X    BBR's delivery-rate estimate (only present under bbr)\n#   retrans:X\/Y  retransmitted \/ total segments\n#   fack, lost, dsack  loss accounting\n#   pacing_rate  the pacer's current target (bbr only)<\/code><\/pre>\n\n\n\n
Under CUBIC, bw<\/code> and pacing_rate<\/code> are absent, so you infer throughput from cwnd<\/code> divided by rtt<\/code>. Under BBR, bw<\/code> is the sender’s own estimate of the bottleneck delivery rate – a much more direct number, and one that stays informative when the connection is application-limited and the cwnd-derived estimate collapses to nonsense.<\/p>\n\n\n\n
Condition<\/th>CUBIC behaviour<\/th>BBR behaviour<\/th>Diagnostic<\/th><\/tr><\/thead>
1% random loss<\/td>halves cwnd, throughput drop<\/td>largely ignores non-congestive loss<\/td>retrans count vs cwnd curve<\/td><\/tr>
128 KB buffer at bottleneck<\/td>loss-driven sawtooth<\/td>probes for the buffer floor<\/td>compare bw to paced rate<\/td><\/tr>
High RTT (150 ms+)<\/td>slow convergence<\/td>converges in ~1 RTT<\/td>rtt field plus bw ramp<\/td><\/tr>
Shallow buffer, no loss<\/td>cwnd grows until loss<\/td>stabilizes below queue limit<\/td>tc -s qdisc backlog<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Measure both without network noise<\/h2>\n\n\n\n
Interleave the two algorithms against the same endpoint within the same minute to cancel out external load:<\/p>\n\n\n\n
for cc in cubic bbr; do\n  sysctl -qw net.ipv4.tcp_congestion_control=$cc\n  echo \"== $cc ==\"\n  curl -o \/dev\/null -s -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\\n' \\\n    --limit-rate 0 https:\/\/mirror.example.net\/100mb.bin\n  sleep 5\ndone\n\n# per-connection retransmit view during the run\nnstat -az TcpRetransSegs TcpExtTCPLostRetransmit TcpExtTCPFastRetrans\n# queue backlog at the egress\ntc -s qdisc show dev eth0<\/code><\/pre>\n\n\n\n
On a VPS, the uplink is usually shared and the bottleneck is frequently the hypervisor’s vNIC or the upstream switch port, not the path. If bw<\/code> plateaus at a value far below your provisioned port rate and tc -s qdisc<\/code> shows a persistent backlog with zero drops, you are queue-limited by the host, and no congestion control change will help. Detecting that early saves a lot of tuning.<\/p>\n\n\n\n
Where BBR is the wrong answer<\/h2>\n\n\n\n
BBR v1 is aggressive about probing for bandwidth and can unfairly starve CUBIC flows sharing a bottleneck, which matters on a VPS whose uplink is policed by the provider. It also does not respond to loss the way operators expect, so a genuinely congested path can show high bw<\/code> estimates while real goodput – the bytes the peer confirms – stays flat. Cross-check with application-level counters, not just ss<\/code>.<\/p>\n\n\n\n