Your gigabit connection is lying to you. The moment a large download starts, your video call freezes and your game stutters—despite a 940 Mbps speed test. The culprit is bufferbloat, and the fix is a free, surgical algorithm called CAKE, which you can deploy on a $50 OpenWrt router in 20 minutes.

What Is Bufferbloat?

Bufferbloat is excessive packet buffering inside network devices, causing latency spikes that wreck interactive traffic. Cheap, large, unmanaged FIFO queues sit in modems, routers, and operating systems under the assumption that more buffer is always better. When a link congests—say, a cloud backup saturates your 50 Mbps upstream—those buffers fill, and packets sit for hundreds of milliseconds before transmission. TCP’s congestion control relies on timely loss or ECN signals to back off, but the bloated buffer soaks up everything, hiding the congestion. The sender keeps ramping up its window, the queue grows, and latency skyrockets.

Picture a 10 Mbps WAN link with a 2 MB FIFO buffer in front of it: client packets → [big dumb buffer] → 10 Mbps egress → internet. When arrival rate exceeds 10 Mbps, the buffer fills. At 2 MB and 1500-byte packets, that’s roughly 1,300 packets queued, taking over 1.5 seconds to drain. A VoIP packet at the back waits 1.5 seconds before ever hitting the wire—a death sentence for real-time conversation. That’s why a single high-bandwidth download makes your VoIP call sound like a robot gargling gravel.

The QoS Landscape: Why Traditional Solutions Fail

Traditional QoS tools are a blunt instrument for home networks. Priority queuing and HTB-based rate limiting require you to classify traffic into neat buckets—VoIP here, web browsing there, BitTorrent at the bottom. That classification is brittle: applications change ports, encrypt everything, and look identical to a stateless classifier. Without constant maintenance, you get a misconfigured mess that punishes the wrong traffic.

HTB can cap total bandwidth to prevent bufferbloat, but it typically couples a single shaper with one FIFO queue per class. One flow within a class can still monopolize the queue and starve others. You need per-flow queuing for fairness between your laptop’s download and your phone’s video call, but classic HTB doesn’t do that natively. You can combine it with fq_codel, but the configuration is fiddly and requires separate shapers for ingress and egress.

fq_codel was the first algorithm designed to kill bufferbloat. It uses a sparse flow queue with a “sojourn time” metric to drop packets from bloated flows, keeping queue delay low. However, it has no built-in shaper—you must pair it with HTB, manually set bandwidth limits just below the true link speed, and guess at link-layer overhead. Set the limit too high, and bufferbloat returns; too low, and you waste capacity. fq_codel is powerful but leaves too much responsibility on the user.

CAKE is the evolved successor that integrates shaping, flow queuing, and a host of clever features into a single, tidy qdisc. It aims to be a complete, self-tuning SQM solution an average home user can deploy without a CCIE.

CAKE: The Common Applications Kept Enhanced Scheduler

The “Kept” in the name is the key insight: CAKE maintains state per flow, per host, or both, and that state is “kept” across multiple packets, enabling informed fairness decisions. At its core, CAKE is a shaper + flow queue combo. It shapes traffic to a configurable rate, properly compensating for link-layer overhead (Ethernet, DOCSIS, ATM, and more), then distributes that shaped bandwidth among internal queues using a variant of DRR with controlled delay.

The flow isolation modes are where CAKE shines. In dual-dsthost (the default), CAKE creates host queues by destination IP, and within each host queue, separate flow queues for individual connections (5-tuple hashes). This prevents one device from hogging the entire link: your son’s game console gets its own host queue, even if he’s pulling 50 simultaneous downloads. triple-isolate adds source IP isolation, useful for multi-tenant setups or when you want fairness between devices even with asymmetric traffic. Per-flow fairness borrows heavily from fq_codel’s sparse flow structure, but with CAKE’s “cobalt” CoDel variant that better handles small packets and ACKs.

CAKE’s Diffserv awareness lets it interpret DSCP markings and sort packets into different internal “tins”—essentially traffic classes with different priority levels. By default, layer_cake.qos maps DSCP into four tins: bulk, best effort, video, and voice. Voice-class traffic gets low-latency treatment, while bulk traffic is de-prioritized. It relies on applications setting proper DSCP values (which many modern apps do, especially for WebRTC and VoIP). CAKE also includes optional ACK filtering, which can drop redundant TCP ACKs to free up upstream bandwidth on highly asymmetric links like DSL.

The autorate option lets CAKE adjust the shaper rate based on observed load, but it’s still experimental and can be twitchy. In practice, most home users will set a fixed rate and forget it. The protocol-first philosophy means you don’t need to understand every tunable; the defaults work remarkably well for typical residential links.

How CAKE Differs from fq_codel

Think of fq_codel as a brilliant algorithm that needs a carefully built enclosure, and CAKE as the complete, pre-assembled appliance. Here’s a table-in-words comparison:

  • Shaping: fq_codel requires an external shaper (HTB, TBF). CAKE has shaping built-in, including link-layer overhead compensation.
  • Overhead compensation: fq_codel has none; you must manually subtract overhead from your rate. CAKE understands Ethernet, DOCSIS, ATM, and can be told exactly what to subtract.
  • Host isolation: fq_codel does per-flow queuing only. CAKE adds per-host isolation (dual-dsthost or triple-isolate), critical for multi-device fairness.
  • Traffic class handling: fq_codel treats all packets equally. CAKE uses Diffserv tins for priority differentiation, though it defaults to a single tin if not configured.
  • ACK filtering: fq_codel doesn’t have it. CAKE can optionally drop redundant ACKs to improve upstream performance.
  • Configuration surface: fq_codel requires you to set the shaper rate, queue length, and manage the interaction. CAKE simplifies to a single rate plus an overhead keyword.

Setting Up CAKE on OpenWrt

OpenWrt’s SQM package makes deploying CAKE almost trivial. Almost, because the router world never quite gives you a free lunch. Start by ensuring your device runs OpenWrt 22.03 or later. CAKE is baked into the kernel (kmod-sched-cake), but the user-space scripts and LuCI frontend need installation.

Installing the SQM Packages

SSH into your router and run:

opkg update
opkg install luci-app-sqm sqm-scripts

This pulls in the necessary dependencies, including kmod-sched-cake if it’s not already present. Verify with tc qdisc add dev eth0 cake (no output means success) or lsmod | grep sch_cake. If you get an error about missing kernel modules, you’re on an older build or a third-party firmware that stripped it out—upgrade OpenWrt. The LuCI interface will appear under Network → SQM QoS.

Configuring the SQM Instance

In LuCI, create a new SQM instance. The important fields:

  • Interface: Your WAN interface (usually eth0.2 or wan for DSL, eth1 for cable). Choose the physical interface, not a VLAN alias.
  • Download / Upload speed: Enter values in kbps. ISPs advertise “up to” speeds you’ll never see sustained. Run a speed test at 3 AM with a wired connection, note the actual throughput, and set your SQM rates to 85–95% of that number. For a 100/10 Mbps cable connection, you might set 90000 kbps down and 9000 kbps up. This headroom prevents the shaper from becoming the bottleneck and allows CAKE to do its job.
  • Queueing Discipline: cake
  • Script: layer_cake.qos (the default, Diffserv-aware) or piece_of_cake.qos (a simpler, single-tin variant for weaker routers)
  • Link Layer Adaptation: Crucial for DSL and cable. If you’re on a VDSL2 line with ATM encapsulation, choose atm and set the per-packet overhead to 44 bytes. Cable modems typically use docsis with 18 bytes of overhead. For Ethernet-to-the-home, ethernet with no extra overhead. Wrong overhead leads to under- or over-utilization, manifesting as either lower throughput or persistent bloat.
  • Advanced options: Enable nat mode if your router is doing NAT (it usually is), which tells CAKE to look at the internal IP addresses for host isolation. Leave wash enabled unless your router is CPU-starved.

Click Save & Apply, then check the status: tc -s qdisc show dev eth0 should show a cake qdisc with the correct bandwidth. The troubleshooting tree for “SQM won’t start”:

  • Is the interface name correct? Check ip link show.
  • Did you forget to install the SQM scripts? which sqm should return a path.
  • Does dmesg complain about a missing cake module? Install kmod-sched-cake.
  • Are you trying to shape a bridge? Shape the underlying physical interface, not br-lan.

Testing and Tuning Your Shaper

The definitive test is a latency-under-load measurement. Use the Waveform Bufferbloat Test (web-based, easy) or the DSLReports speed test (if it still works in your region). For a more professional approach, run a Flent RRUL (Realtime Response Under Load) test. RRUL floods the link with flows while measuring ICMP or UDP pings, producing a plot that shows latency over time. A good result: base latency stays flat during the entire test, with no spikes. A bad result: a sawtooth of latency spikes climbing to 200ms as the test progresses.

If you still see bloat, lower your SQM rates by 5% increments until the loaded latency matches the idle. Don’t obsess over losing a few Mbps; the trade-off is a connection that feels fast for everything rather than a number that looks good on a speed test. The cake bandwidth autorate option can do this dynamically, but it’s still experimental and can oscillate. I prefer fixed rates set once after a careful measurement.

Reading a Flent RRUL Plot

Picture a graph with time on the x-axis and latency on the y-axis. A well-configured CAKE shaper produces a flat, horizontal line hugging the base latency, with perhaps a tiny 1–2ms bump at the start. A bufferbloated link shows a diagonal rise, followed by erratic spikes and drops as TCP backs off and the queue drains. The “sawtooth” pattern is the telltale sign of uncontrolled buffers. If your plot looks like a mountain range, you haven’t solved bloat yet.

Troubleshooting Common CAKE Issues

After enabling CAKE, you might encounter a few head-scratchers. Speeds that are too low often come down to incorrect overhead compensation or setting the rate too conservatively. If you’re on a cable modem, double-check that you’ve selected docsis and the right overhead (ask your ISP if you’re unsure, or experiment). For pure Ethernet, disable overhead entirely. If throughput is still anemic, raise the SQM limits slightly—remember, the 85% rule is a starting point, not gospel.

VoIP or video calls that remain choppy despite CAKE often point to a fairness mode issue. If you have a lot of internal traffic, switch from dual-dsthost to triple-isolate to separate source and destination hosts. Also, ensure that your VoIP device is marking packets with DSCP EF (46) and that layer_cake.qos is active; without Diffserv awareness, voice packets compete equally with bulk downloads. You can verify with tc -s qdisc show dev eth0 and look for bytes in the voice tin.

On routers with weak CPUs (like single-core MIPS devices), CAKE can chew up processing cycles. The piece_of_cake.qos script uses a single tin and disables some features to reduce overhead. Turning off wash (DSCP marking wash) and ack-filter also helps. If you see high CPU usage, monitor with htop and consider upgrading to a device with hardware offload support—though CAKE itself is always software-queued.

A decision tree for “something’s still not right”:

  1. Run RRUL. Is latency flat? If yes, stop worrying.
  2. If latency spikes, lower SQM rates by 5% and retest.
  3. If speeds are unacceptably low, check overhead and raise rates, but accept that you’ll trade some throughput for latency.
  4. If one device still dominates, switch to triple-isolate and/or enable per-host fairness.
  5. If CPU is maxed, switch to piece_of_cake.qos and disable non-essential options.

Conclusion

CAKE isn’t magic, but it’s the closest thing home networking has to a one-click fix for bufferbloat. It integrates shaping, flow queuing, host isolation, and Diffserv classification into a single qdisc that turns a jittery, unreliable link into a predictable pipe. The 20 minutes you spend installing and tuning it on OpenWrt will pay dividends every time you can game, stream, and video call simultaneously without a single stutter. Forget the ISP’s marketing numbers; real network quality is measured in flat latency plots, not speed test screenshots. Set your rates honestly, enable the right overhead, and let CAKE keep the state—so you don’t have to keep the frustration.