{"id":1516,"date":"2026-10-26T22:42:38","date_gmt":"2026-10-26T22:42:38","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1516"},"modified":"2026-10-26T22:42:38","modified_gmt":"2026-10-26T22:42:38","slug":"bbr-fq-vs-cake-fq-codel-single-vcpu-triage","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/bbr-fq-vs-cake-fq-codel-single-vcpu-triage\/","title":{"rendered":"BBR + fq vs CAKE + fq_codel: Picking a Queue Discipline on a Single-vCPU VPS"},"content":{"rendered":"
\n

Everyone has already enabled BBR. The question on a single-vCPU box is not which congestion control to use, it is what you pair it with \u2014 BBR plus fq, or the fq_codel queueing that CAKE builds on. Both work; they fail differently under saturation, and the CPU cost is not the same when you only have one core. This is a measurement methodology you can run on a $10 instance in about forty minutes, with the specific counters to read. Whether your provider’s kernel exposes the needed qdiscs is a separate question worth checking in the VPS provider list supporting modern kernels<\/a>.<\/p>\n

Why the Pairing Matters More Than BBR<\/h2>\n

BBR is a congestion control algorithm: it decides send rate. fq and CAKE are queue disciplines: they decide what happens to packets waiting to leave the interface. BBR estimates bottleneck bandwidth and round-trip time and paces packets to match. That pacing assumes a queue discipline that spreads packets out rather than dumping bursts \u2014 which is why the canonical pairing is BBR + fq. CAKE does the same spreading plus per-host fairness and optional shaping, but it computes a shaper and a hash per flow, and on one vCPU that computation competes with your application.<\/p>\n

sysctl -n net.ipv4.tcp_congestion_control\nsysctl -n net.core.default_qdisc\ntc qdisc show dev eth0<\/code><\/pre>\n
Expected on a stock Ubuntu 24.04 kernel: cubic<\/code>, fq_codel<\/code>, and qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms<\/code>. If you see noqueue<\/code>, the interface is a virtual NIC that hands packets straight to the hypervisor and qdisc changes will have limited effect \u2014 check that before benchmarking anything.<\/p>\n
The Two Stacks, Precisely<\/h2>\n
# Stack A: BBR + fq\nsysctl -w net.core.default_qdisc=fq\nsysctl -w net.ipv4.tcp_congestion_control=bbr\ntc qdisc replace dev eth0 root fq maxrate 900mbit\n\n# Stack B: CAKE + fq_codel leaves (CAKE's internal default)\nsysctl -w net.core.default_qdisc=fq_codel\nsysctl -w net.ipv4.tcp_congestion_control=bbr\ntc qdisc replace dev eth0 root cake bandwidth 900mbit diffserv4<\/code><\/pre>\n
Two details people skip. First, maxrate<\/code> on fq is what makes BBR pace properly; without it fq spreads packets but doesn’t shape, and you lose the pacing benefit at rates above the link. Second, CAKE’s bandwidth<\/code> must be set below the real link rate \u2014 900 Mbit on a 1 Gbit port \u2014 or the shaper never engages and CAKE behaves like a more expensive fq_codel. If you set the bandwidth above the physical rate, you are measuring nothing.<\/p>\n
What to Measure, and With What<\/h2>\n
CPU cost, latency under load, retransmits, and throughput \u2014 in that order of importance on a single vCPU. A stack that gains 5% throughput and costs 20% CPU is a net loss when that CPU runs your web server.<\/p>\n
# CPU cost of the qdisc itself, excluding the app\npidstat -u 1 30 | awk '\/%CPU\/ || \/ksoftirqd|kworker\/'\n\n# Per-socket state during the test\nss -tin dst TARGET_IP | grep -E 'bbr|cwnd|rtt|retrans|snd'\n\n# Retransmit and loss counters\nnstat -az TcpRetransSegs TcpOutSegs TcpExtTCPLostRetransmit<\/code><\/pre>\n
The ss -tin<\/code> output is where the useful signal lives. On BBR you will see bbr<\/code> in the algorithm field along with bw:<\/code> and mrtt:<\/code> estimates. rcv_ssthresh<\/code> shows how much receive window the kernel is willing to open \u2014 if it’s pinned low, you’re being limited by the receiver or by an undersized socket buffer, not by the congestion control, and the whole A\/B test is measuring the wrong thing.<\/p>\n
Test 1: Bufferbloat Under Saturation<\/h2>\n
Generate a saturating upload from one client while pinging a third host, and look at RTT inflation rather than average throughput.<\/p>\n
# Terminal 1: saturate the uplink\niperf3 -c TARGET -t 60 -P 4\n\n# Terminal 2: latency under load, 100 pings at 200ms\nping -i 0.2 -c 300 OTHER_HOST | tail -3<\/code><\/pre>\n
Baseline idle RTT to the third host: 14 ms. Under load with fq_codel<\/code> and no shaping, expect 60\u2013180 ms and jitter \u2014 the classic bufferbloat signature, because the qdisc has no target rate to pace against. With BBR + fq maxrate 900mbit<\/code>, RTT under load typically lands at 16\u201328 ms. With CAKE at 900 Mbit, 16\u201324 ms with noticeably tighter jitter. The difference between A and B here is usually small; the difference between either and leaving the default fq_codel<\/code> is large. That comparison is the one worth running first.<\/p>\n
Test 2: Retransmits and Loss Recovery<\/h2>\n
nstat -n > \/dev\/null            # reset counters\niperf3 -c TARGET -t 60 -P 4\nnstat TcpRetransSegs TcpOutSegs TcpExtTCPLostRetransmit\nawk '\/TcpRetransSegs|TcpOutSegs\/ {print $2, $3}' \/proc\/net\/netstat<\/code><\/pre>\n
Compute the ratio, not the absolute count: TcpRetransSegs \/ TcpOutSegs<\/code>. Under 0.1% is clean. Between 0.1% and 1% suggests a lossy path. Above 1% and BBR is doing its job anyway \u2014 it reacts to delivery rate rather than loss \u2014 but your users see stalls. If CAKE shows materially lower retransmits at the same throughput, the shaper is smoothing bursts that were overflowing a downstream buffer. If the numbers are identical, the downstream bottleneck is elsewhere and the qdisc choice is not your problem.<\/p>\n
Test 3: CPU Cost on One vCPU<\/h2>\n
Run the same 60-second iperf3 three times per stack and record ksoftirqd<\/code> plus total system CPU from pidstat<\/code>. On a single vCPU with one 1 Gbps flow, the realistic numbers are: fq<\/code> at roughly 3\u20136% of the core, cake<\/code> at roughly 12\u201322% with diffserv4<\/code>. CAKE’s per-packet hashing, DSCP classification and shaper token accounting cost real cycles, and those cycles come out of the same core running nginx.<\/p>\n
# Isolate: one stream, then ten\nfor p in 1 4 10; do\n  iperf3 -c TARGET -t 30 -P $p --json | jq \".end.sum_sent.bits_per_second\/1e6\"\ndone<\/code><\/pre>\n
Watch how the CPU gap scales with stream count. fq’s cost is close to flat \u2014 more flows just means more hash buckets. CAKE’s rises because per-flow classification continues and the shaper does more work per second at higher packet rates. Past roughly 8,000 pps of sustained traffic on one vCPU, CAKE becomes a visible fraction of your headroom.<\/p>\n
When Each Wins<\/h2>\n\n\n\n\n\n\n\n\n\n
Situation<\/th>\nPreference<\/th>\nReason<\/th>\n<\/tr>\n<\/thead>\n
Web server, 1 vCPU, <2k pps<\/td>\nBBR + fq<\/td>\nLowest CPU cost, pacing intact<\/td>\n<\/tr>\n
Shared host with bursty neighbours<\/td>\nCAKE + shaping<\/td>\nPer-host fairness caps your own bursts<\/td>\n<\/tr>\n
Uplink smaller than LAN (50\/100 Mbit)<\/td>\nCAKE at 95% link rate<\/td>\nShaping prevents upstream bufferbloat<\/td>\n<\/tr>\n
Max throughput, CPU-bound app<\/td>\nBBR + fq maxrate<\/td>\nCAKE’s shaper spends cycles you need<\/td>\n<\/tr>\n
Many tenants behind one NIC<\/td>\nCAKE diffserv4<\/td>\nPriority classes without tc filters<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Pitfalls That Invalidate the Test<\/h2>\n