SQM Setup: Fix Bufferbloat with Cake or fq_codel

You tested your line, watched your ping jump from 20 ms to 400 ms the moment anyone downloaded anything, and learned the name of your enemy: bufferbloat. This is the hands-on half of the fix, actually configuring smart queue management (SQM) with Cake or fq_codel on your router so a download can never make your game packets wait in line again. The concepts are in Bufferbloat Explained; this page is the wrench work.

What is SQM and why does it fix bufferbloat?

SQM (smart queue management) is active queue management running on your router: algorithms like Cake and fq_codel keep the packet queue short and share it fairly between flows, so one big download can’t make your game packets wait behind it. Bufferbloat is the disease it cures: oversized buffers in routers and modems that hold packets for hundreds of milliseconds whenever the line gets busy.

Cake and fq_codel descend from CoDel, the active queue management algorithm standardized as RFC 8289, designed to hold queuing delay near a small target instead of letting buffers fill to the brim.

The trade you make is deliberate: you cap throughput at roughly 90–95% of your line rate so that your router, not the ISP’s modem, becomes the bottleneck. Queues always build at the bottleneck; by moving the bottleneck to a device where an algorithm manages the queue, the queue stays short everywhere that matters. You lose a few percent of peak speed and get back a connection that behaves the same under load as it does idle.

How do you set up SQM on OpenWrt?

OpenWrt ships the friendliest SQM setup around through its LuCI web interface. The full official reference is the OpenWrt SQM documentation; here is the short path:

1. Install the package. Update package lists and install luci-app-sqm: in LuCI go to System → Software, or over SSH run opkg update && opkg install luci-app-sqm.
2. Open Network → SQM QoS and enable it on the WAN interface, the one facing the internet. On most setups that’s wan; on PPPoE links it’s pppoe-wan. Picking the wrong interface is the number-one silent failure.
3. Set download and upload speed to ~90–95% of your measured line rate, in kbit/s. Measure first, while the line is idle: a throughput speed test is the right tool for this one job, it measures capacity, which is exactly the number SQM needs. Don’t trust the figure on your ISP bill. If your line rate drops at busy times of day, measure in the evening and tune to the congested rate.
4. Choose the queue discipline. Use cake with the piece_of_cake.qos script, the simplest good default. On weaker hardware that can’t run Cake at line rate, use fq_codel with simple.qos instead. On asymmetric links set per-direction rates; on DSL lines set the correct link-layer adaptation, the OpenWrt docs cover the per-technology details better than we can here.
5. Save & Apply, then verify with the stress test in the next section.

How do you verify SQM actually worked?

Never configure blind, measure before and after. The loop:

1. Before: run LagScope’s 8-second stress test and note your idle vs loaded latency. The loaded number is the bufferbloat you’re about to kill.
2. Configure SQM per the steps above.
3. After: run the stress test again. Success looks like loaded latency collapsing to near-idle levels, the same saturation that used to add hundreds of milliseconds now adds nearly nothing.
4. Then the real test: keep the LagScope monitor running through a genuinely busy evening session. The lagspikes (sustained ≥500 ms events) that downloads used to trigger should simply stop appearing in the event log, and your score should move out of WOOD/SILVER territory.

If nothing changed, the two classic mistakes are a wrong interface (SQM enabled on wan when your link is really pppoe-wan, or vice versa) and a bandwidth value above the real bottleneck, if the configured rate exceeds what the line actually delivers, the queue builds upstream in the ISP’s equipment again, out of Cake’s reach. Drop the values another 5% and re-test.

Why won’t my ISP router’s built-in “QoS” fix this?

Reality check: the “QoS” page on most ISP combo boxes is device priority, not queue management. It decides whose packets go first when the line saturates, but the oversized buffer is still there, still filling, still delaying everything behind it. Priority shuffles the order of a queue that should never have gotten long; it never shortens the queue. That is not AQM, and it does not fix bufferbloat.

Some newer gaming and prosumer routers do ship real SQM under names like “Smart Queue Management” or “anti-bufferbloat.” The tell: a real implementation asks for your bandwidth (it needs to own the bottleneck), while fake QoS only asks for a priority list of devices or apps.

When the ISP box can’t do SQM and can’t be replaced outright, the standard answer is bridge mode: put the ISP box in bridge/modem-only mode so it stops routing, and let your own OpenWrt (or otherwise SQM-capable) router handle the queue. More on that layout in Router Setup for Gaming.

Frequently asked questions

Will SQM slow my downloads?

Yes, deliberately, by about 5–10%. SQM only works if you cap throughput slightly below your real line rate (90–95%), so your router’s managed queue becomes the bottleneck instead of the ISP’s unmanageable one. In practice a download that would have run at 100% now runs at ~92%, but your game ping stops exploding while it runs. Most gamers consider a 100 GB update finishing a few minutes later a fine price for zero lagspikes.

What bandwidth values should I enter in SQM?

90–95% of your measured line rate, in kbit/s, measured, not the number on your ISP bill. Run a throughput speed test while the line is idle and treat the result as your 100% baseline. If speeds vary by time of day, measure during the congested evening hours and tune to that. Set download and upload separately, and remember SQM wants kilobits: 95% of a 400/20 Mbit/s line is 380000 down and 19000 up.

Does SQM work on gigabit fiber?

The algorithm does; your router’s CPU may not. Shaping with Cake costs real CPU per packet, and many consumer routers can’t run it at multi-hundred-Mbit or gigabit rates, shaping silently degrades when the CPU maxes out. The honest options: try fq_codel with simple.qos (cheaper than Cake), use a router with a stronger CPU, or skip shaping and just manage when the household saturates the line. At gigabit speeds a bloated buffer drains fast, so the pain is real but shorter-lived than on slower links.

My router has no OpenWrt support, what are my options?

First check whether it ships real SQM under a marketing name: many gaming and prosumer routers expose Cake, fq_codel or an equivalent as “Smart Queue Management” or “anti-bufferbloat”, look for a bandwidth-limited smart queue, not a priority list. If it genuinely can’t, put the ISP box in bridge mode and add your own SQM-capable router behind it (see Router Setup for Gaming). Last resort: plain bandwidth-limit QoS set below line rate, cruder than Cake, but it prevents saturation and keeps latency flat.

Does SQM help on Wi-Fi?

It fixes the queue at your router, not the airtime contention on your wireless link. SQM stops downloads from queueing your game packets behind bulk traffic, that helps every device, wired or wireless. But Wi-Fi adds its own latency spikes from interference, retransmissions and neighbors sharing the channel, and no queue discipline fixes radio physics. If your stress test passes after SQM but games still spike, the wireless link is the next suspect, see Wi-Fi vs Ethernet for Gaming.