Optimizing Latency and Eliminating Bufferbloat on Linux with CAKE and FQ-CoDel - ITFROMZERO - Share tobe shared! Ping spikes under heavy network load are caused by Bufferbloat. This guide compares FQ-CoDel and CAKE, providing detailed Linux tc configuration steps to stabilize latency and eliminate congestion.

Table of Contents

Comparing Bufferbloat Mitigation Solutions on Linux

You are typing smoothly in an SSH session when a colleague suddenly starts a torrent download or backs up 50GB to the cloud, causing your ping to skyrocket from 15ms to 450ms. This is the classic symptom of Bufferbloat. Network devices aggressively buffer excessive packets to prevent TCP packet drops. As a result, queues bloat, leaving latency-sensitive packets—like DNS lookups, SSH keystrokes, and VoIP calls—stuck in line behind bulk transfers.

Linux provides three common queuing disciplines (qdiscs) to address this issue:

Default FIFO (pfifo_fast): The classic first-in, first-out queue. Packets are processed in the exact order they arrive. When a single stream saturates bandwidth, the buffer fills up, causing lag across every other connection.
FQ-CoDel (Fair Queuing Controlled Delay): Divides traffic into 1,024 separate sub-queues. The CoDel algorithm automatically drops packets or marks them with ECN when queues begin to bloat. FQ-CoDel has been built into the Linux kernel since version 3.5.
CAKE (Common Applications Kept Enhanced): A comprehensive upgrade over FQ-CoDel designed for edge routers. CAKE includes a built-in bandwidth shaper, automatically compensates for physical layer overhead (PPPoE, Ethernet framing), and allocates traffic fairly on a per-host basis.

Technical Pros and Cons: FQ-CoDel vs. CAKE

Each algorithm tackles bottlenecks at a different point in your network infrastructure:

1. FQ-CoDel

Pros:

Extremely low CPU overhead; runs smoothly on everything from 1 vCPU instances to Linux switches handling tens of Gbps.
Requires zero complex tuning. The algorithm self-adjusts based on real-world network RTT.
Ready to use out of the box on virtually all Linux distributions without external modules.

Cons:

No built-in traffic shaper. To throttle WAN interface bandwidth and force the queue to build up inside Linux, you must pair FQ-CoDel with HTB using tedious, lengthy tc commands.
Only balances traffic by 5-tuple (source/dest IP, source/dest port, and protocol). A multi-threaded download client opening 40 connections can still overpower a machine running a single interactive session.

2. CAKE (qdisc_cake)

Pros:

Features an exceptionally stable integrated bandwidth shaper. You only need a single command instead of setting up a complex HTB hierarchy.
Supports triple-isolate mode: allocates bandwidth fairly per host rather than per flow. A single IP cannot hog bandwidth from the entire office network.
Automatically calculates and compensates for physical layer overhead (e.g., FTTH PPPoE, VLAN, DOCSIS), preventing packets from unexpectedly buffering in the ISP modem.
Automatically recognizes and prioritizes packets based on DiffServ (DSCP) markings without requiring manual iptables/nftables rules.

Cons:

Consumes roughly 15–25% more CPU than FQ-CoDel due to multi-tier hashing and overhead framing calculations.
Requires Linux kernel 4.19 or later (supported out of the box in Ubuntu 20.04+, Debian 10+, etc.).

Choosing the Right Solution for Your Setup

You should not default to CAKE in every scenario:

Choose FQ-CoDel for: Standalone servers, Kubernetes clusters, or 10Gbps/40Gbps internal interfaces where the machine’s interface is not the bottleneck. FQ-CoDel maintains ultra-low latency with near-zero computational overhead.
Choose CAKE for: Edge routers, office Linux gateways, or homelabs dialing PPPoE to the Internet. When a 200Mbps connection is plugged into a 1Gbps NIC, CAKE excels through its integrated shaper, shifting queue management control back to Linux.

Step-by-Step Configuration Guide on Linux

Step 1: Check the Current qdisc and Measure Bufferbloat

First, inspect which queuing discipline your primary network interface is currently using:

# Check the queuing discipline on the eth0 interface
tc qdisc show dev eth0

If the terminal simply returns pfifo_fast or mq, your system does not currently have active queue management enabled.

You can quickly test latency by opening two terminal windows: run ping 1.1.1.1 in one, and download a large file using curl -O or run iperf3 in the other. If your ping spikes from 20ms up to 200–300ms, your connection suffers from severe Bufferbloat.

Step 2: Enable FQ-CoDel for Standalone Servers

For web servers, database nodes, or standard virtual machines, you only need to attach FQ-CoDel directly to your network interface:

# Replace the default qdisc with fq_codel on eth0
sudo tc qdisc replace dev eth0 root fq_codel

# View status and packet statistics
tc -s qdisc show dev eth0

The output will show packet drops, ecn_mark counts, and active flow metrics. FQ-CoDel automatically balances traffic so that no single flow can monopolize the queue for too long.

Step 3: Configure CAKE on a Linux Router / Gateway

The golden rule of anti-bufferbloat management: set the shaper to 90%–95% of your line’s actual bandwidth capacity. This guarantees that queues form inside Linux rather than overflowing into the ISP modem.

Before subnetting internal networks, you can quickly verify network ranges and host counts using toolcraft.app/en/tools/developer/ip-subnet-calculator to avoid subnet mask misconfigurations.

Assuming your outbound WAN interface is eth0 on a 100Mbps plan (with a measured stable throughput of 95Mbps):

# Configure CAKE shaper at 90Mbps, compensate for Ethernet overhead, isolate per host:
sudo tc qdisc replace dev eth0 root cake bandwidth 90mbit ethernet triple-isolate nonat

# If this interface performs outbound NAT directly, enable the nat flag so CAKE tracks conntrack:
sudo tc qdisc replace dev eth0 root cake bandwidth 90mbit ethernet nat dual-srchost

Monitor the operational status immediately after applying the configuration:

tc -s qdisc show dev eth0

The output clearly displays target delay (typically around 5ms), current buffer usage, dropped packet counts, and ECN marking rates.

Step 4: Persist Configurations Across Reboots

Standard tc commands do not persist after a system restart. To make these rules permanent, the cleanest approach is to create a systemd service.

Open /etc/systemd/system/cake-sqm.service:

sudo nano /etc/systemd/system/cake-sqm.service

Add the following configuration (make sure to replace the interface and bandwidth values with your own):

[Unit]
Description=Apply CAKE SQM to eth0
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/sbin/tc qdisc replace dev eth0 root cake bandwidth 90mbit ethernet nat dual-srchost
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now cake-sqm.service

Now, stress test your connection again. Even under 100% bandwidth saturation, your ping should only deviate by 1ms to 5ms compared to idle state.