Cake SQM on OpenWrt: Getting an A+ Bufferbloat Score

To get an A+ bufferbloat grade on OpenWrt, install SQM, choose the cake queue discipline, shape both directions to a little below the speed your line really delivers, and tell cake how much overhead each packet carries on the wire. On my 200/200 Mbps home fibre line, with OpenWrt on a small x86 box, shaping to about 190 Mbps each way scores A+ on both Waveform’s and LibreQoS’s bufferbloat tests. Calls and games stay smooth while the line is flat out.

What bufferbloat is, and why SQM fixes it

When a line is busy, packets queue up somewhere. Without SQM, that queue sits in the fibre terminal or the provider’s equipment, where nothing manages it: it fills up, and every packet waits behind it. A download running in the background then adds tens or hundreds of milliseconds to every game packet and video call. That extra delay under load is bufferbloat.

SQM (smart queue management) moves the queue onto your router by sending slightly slower than the line can carry. The line’s own buffers never fill, and the queue that does form is one cake can manage: it shares bandwidth fairly between connections and between devices, and drops or marks packets early so senders slow down before the delay builds.

Measure the line first

A baseline tells you where to shape and whether the change worked. Run a bufferbloat test before changing anything, from a wired computer with nothing else busy on the network:

• Waveform’s bufferbloat test reports speeds and how much latency rises during download and upload, with a grade.
• LibreQoS’s bufferbloat test loads the line in both directions and reports how latency behaves under load. It’s stricter than Waveform’s.

Write down three numbers: download speed, upload speed, and the latency increase under load. The speeds tell you where to shape; the latency tells you whether it worked.

Waveform grades how much latency rises under load:

Grade	Latency increase
A+	Under 5 ms
A	5 to 29 ms
B	30 to 59 ms
C	60 to 199 ms
D	200 to 400 ms
F	Over 400 ms

Install SQM on OpenWrt 25.12

OpenWrt 25.12 replaced opkg with apk. Over SSH:

apk update
apk add luci-app-sqm

luci-app-sqm pulls in sqm-scripts and the cake kernel module. Refresh LuCI and the settings appear under Network > SQM QoS.

Turn off flow offloading

Under Network > Firewall, LuCI warns that routing and NAT offloading is “not fully compatible with QoS/SQM”. Hardware offloading hides packets from SQM entirely, and software offloading is uncertain enough that it’s simpler to switch both off. On a router fast enough to run cake at your line speed, you won’t miss them.

Configure cake

All the settings live on one page, Network > SQM QoS, spread over three tabs.

Basic Settings

• Tick Enable this SQM instance.
• Interface name: the WAN device. On a DHCP or static-IP fibre connection that’s the physical WAN port, such as eth1 or wan. On a PPPoE connection choose pppoe-wan.
• Download speed and Upload speed, in kbit/s: about 95% of what you measured. For a line that tests at 200 Mbps, start at 190000 for each.

Queue Discipline

• Queueing discipline: cake.
• Queue setup script: piece_of_cake.qos. It runs cake with a single priority tier, which is all most homes need. layer_cake.qos adds priority tiers based on DSCP markings, which only help if something on your network sets them.

Link Layer Adaptation

• Link layer: Ethernet with overhead.
• Per Packet Overhead (bytes): 44 for fibre. If SQM sits on pppoe-wan, use 52, because the kernel doesn’t see the 8-byte PPPoE header on that interface.
• Tick Advanced Linklayer Options and set Minimum packet size to 84.

Save and apply.

Check cake is running

tc -s qdisc show dev eth1
tc -s qdisc show dev ifb4eth1

Use your own WAN interface name. The first shows the upload side; the second shows the download side, which sqm-scripts shapes on a virtual device named ifb4 plus the interface name (for PPPoE, ifb4pppoe-wan). Both should list cake with your bandwidth, and the packet counters should climb during a test.

Test, then tune

Rerun both tests from the same wired computer.

• A+ or A on Waveform: done. You can try creeping the speeds up in steps of 2–3% to win back bandwidth, retesting each time.
• Latency rises more during download than upload: lower only the download speed by 5% and retest. Shaping incoming traffic is harder, because the packets have already crossed the line by the time the router sees them, so download usually needs more margin.
• Latency still rises at both ends: check the overhead values and that offloading is off.
• Speeds well below your settings and latency spikes: the router’s CPU can’t keep up.

The router has to keep up

Plain cake shapes each direction on a single CPU core, so a router’s single-core speed sets the most it can shape. When the CPU runs out, latency spikes come back, which looks just like bufferbloat.

Recent OpenWrt 25.12 releases also include cake_mq, which spreads the shaping across cores on network cards with several transmit queues. sqm-scripts uses it when use_mq is set. The 25.12 LuCI page doesn’t show that option yet, so set it over SSH:

uci set sqm.@queue[0].use_mq='1'
uci commit sqm
/etc/init.d/sqm restart

Check with tc -s qdisc afterwards; on a card with a single queue, nothing changes.

My router is a modest x86 board with a 2-core Celeron, and cake at 200 Mbps barely moves it. Many inexpensive ARM routers top out well below gigabit with cake. If yours struggles, a small x86 box running OpenWrt is the usual upgrade, or shape slightly lower and accept a little less speed for a lot less lag.

Check it worked

• Waveform shows A or A+, and the latency increase during download and upload is a few milliseconds.
• LibreQoS’s test shows only a small latency increase under load.
• A large download running on one computer doesn’t make a video call on another stutter.

If latency is fine under load but you still see drops or spikes at quiet times, that’s a different problem, usually in the provider’s network. A ping graph over hours, hop by hop, is the evidence you’ll need for them; that’s what pingrail is for.