The Two Ideas Inside FQ-CoDel
| Part | What It Means | Practical Benefit |
|---|---|---|
| Flow queueing | Packets are grouped by traffic flow instead of thrown into one big line | A backup upload is less able to crowd out a game or call |
| CoDel | Controlled Delay watches how long packets sit in queues | Old, bloated queues are reduced before latency gets ugly |
The Problem FQ-CoDel Solves: Bufferbloat
Modern routers and modems contain large buffers — memory used to hold packets when a link is busy. The original reasoning was that bigger buffers prevent packet loss. The unintended consequence is that when a link is saturated, those buffers fill up and packets sit in queue for hundreds of milliseconds before being transmitted. This is bufferbloat: a connection that shows 100 Mbps on a speed test but delivers 400–600 ms ping the moment someone starts a large upload.
The deeper problem is that traditional tail-drop queues react only when the buffer is completely full, which is already far too late. By that point the queue contains many seconds of backlogged packets and every new interactive packet — a game update, a DNS query, a video call frame — waits behind all of them.
Why One Big Queue Is a Problem
A simple router queue treats a tiny game packet and a huge stream of upload data as part of the same line. If the upload fills the queue, your game packet waits. That wait time is latency. Enough waiting becomes a ping spike, a frozen call, or a web page that feels oddly slow while the speed test still looks fine.
FQ-CoDel changes the shape of that line. Different flows get separate queues, and the scheduler rotates between them using a stochastic fair-queuing algorithm. A bulk transfer can still use the connection, but it cannot occupy the head of the queue for every packet. Interactive traffic gets served between each bulk chunk.
How CoDel Decides a Queue Is Too Deep
CoDel focuses on packet sojourn time: how long a packet has spent in the queue from arrival to transmission. Each packet is timestamped when it enters. If a packet's sojourn time exceeds a target threshold (typically 5 ms) for longer than a control interval (typically 100 ms), CoDel begins dropping or ECN-marking packets. Those drops signal TCP senders to reduce their congestion window and back off — which is exactly what TCP's congestion control is designed to respond to.
This is fundamentally different from waiting until a buffer is full. Full-buffer tail-drop reacts too late, after hundreds of milliseconds of backlog have accumulated. CoDel reacts to delay early, keeping the queue shallow and latency low even under sustained load. The key insight is that packet loss triggered by CoDel is a controlled signal, not a failure — it tells the sender to slow down before the situation becomes severe.
FQ-CoDel vs Plain FIFO Under Load
| Condition | Plain FIFO Queue | FQ-CoDel |
|---|---|---|
| Idle connection | Low latency | Low latency |
| One bulk upload active | Ping rises to 300–600 ms | Ping stays near idle baseline |
| Multiple flows competing | Large flow dominates, small flows starve | Each flow gets fair share of service |
| Burst traffic | Buffer fills, late packets dropped | CoDel drops early, TCP backs off quickly |
Where FQ-CoDel Shows Up
- Linux kernel networking stack — available as a qdisc since kernel 3.3 and widely deployed in Linux-based routers and servers.
- OpenWrt SQM package — selectable as the queue discipline alongside a bandwidth shaper.
- Some stock router firmware that exposes modern queue management options.
- Network devices that need good default latency behavior without hand-tuned per-application QoS rules.
CAKE as the Successor
CAKE (Common Applications Kept Enhanced) builds on the same goals as FQ-CoDel but adds features specifically useful for home internet connections: an integrated bandwidth shaper, per-host fairness isolation, overhead compensation for DSL and PPPoE framing, and a simplified traffic class system. For home users tuning a single internet bottleneck, CAKE is typically the more complete and easier-to-configure choice. FQ-CoDel remains the right option when a separate shaper is already in place, or when running on infrastructure where CAKE's additional complexity is unnecessary.
Enabling and Testing on OpenWrt
In OpenWrt, install the luci-app-sqm and sqm-scripts packages. Under Network → SQM QoS, select your WAN interface, set download and upload bandwidth to roughly 90–95% of your measured speeds, and choose fq_codel (or cake) as the queue discipline. After saving, run a bufferbloat test at DSLReports or Waveform with the feature enabled and disabled to confirm the improvement. A well-configured connection should score an A or B on the bufferbloat grade, with loaded ping staying close to idle ping.
How To Know It Is Working
Run a bufferbloat test or keep a continuous ping running while saturating upload and download simultaneously. Without FQ-CoDel, ping under load typically climbs to several hundred milliseconds. With FQ-CoDel active and correctly shaped, the loaded ping should stay within a small multiple of your idle ping — often under 20–30 ms even at full link saturation. The goal is simple: busy should not mean unusable.
Frequently Asked Questions
What does FQ-CoDel stand for?
FQ-CoDel stands for Flow Queue Controlled Delay. It combines stochastic fair queueing with the CoDel active queue management algorithm.
Does FQ-CoDel replace QoS?
For latency control, it can replace many manual QoS rules. It does not need to identify every app because it focuses on per-flow fairness and queue sojourn time rather than application classification.
Is FQ-CoDel the same as CAKE?
No. CAKE pursues similar goals but bundles more home-router features — an integrated shaper, overhead compensation for DSL/PPPoE/ATM framing, per-host fairness, and a traffic class system. FQ-CoDel is simpler and requires a separate shaper to fully control the bottleneck.