OpenWrt SQM einstellen: CAKE-Setup, das wirklich wirkt
SQM mit dem cake-Queue-Disziplin ist die Standardlösung gegen Bufferbloat auf OpenWrt — aber zwischen sqm-scripts, Bandbreiteneintrag und Presets wird leicht falsch konfiguriert. Diese Seite erklärt jede wichtige Einstellung, welches CAKE-Preset wofür gedacht ist, und die gemessenen Zahlen unseres Prüfstands (Stand 2026-11).
Die SQM-Einstellungen, die zählen
| Einstellung (LuCI → Netzwerk → SQM QoS) | Eintragen | Warum |
|---|---|---|
| Aktiviert | Häkchen | Ohne SQM keine Formung |
| Schnittstelle | WAN-Interface (eth0, pppoe-wan) | Formung muss am Engpass sitzen |
| Download (kbit/s) | Gemessen × 0,85–0,90 | Reserve für Overhead; Tarifgeschwindigkeit überschätkt |
| Upload (kbit/s) | Gemessen × 0,85–0,90 | Das wichtigste Feld — Uploads lösen Bufferbloat aus |
| Queue-Disziplin | cake | AQM hält die Queue kurz; alte htb-Queues meiden |
| Queue-Setup-Skript | piece_of_cake (Start) | Vorkonfiguration für den Normalfall |
Messwerte gewinnen: drei Speedtests zur ruhigen Tageszeit, Median nehmen, 10–15 % abziehen, in kbit/s eintragen. Bei Provider- oder Tarifwechsel neu messen.
CAKE-QoS-Presets: piece_of_cake vs. diffserv4 vs. besteffort
- piece_of_cake (Standard) — diffserv0, bester Kompromiss für gemischten Hausverkehr. Im Zweifel: hier bleiben.
- diffserv4 — vier DSCP-Prioritätsebenen (Bulk/Best Effort/Video/Sprach), sinnvoll bei VoIP, kostet etwas CPU.
- besteffort — eine Ebene, kein DSCP; für sehr schwache CPUs oder Fehlersuche.
Die Foren-Begriffe cake qos, qos layer und diffserv mappen genau
auf diese Presets — es gibt kein separates „cake-qos“-Paket.
Gemessen: vorher vs. nachher
Prüfstand: NanoPi R5C (4× Cortex-A55) · 1000M↓/50M↑ DSL. 16-thread saturated download 30 s × 2, concurrent ping, 2-run mean.
| Metrik | AUS | NetSteer AN | Änderung |
|---|---|---|---|
| Avg full-load latency | 58.6 ms | 7.8 ms | ↓ 87% |
| Full-load spread (p99−p50) | 56.4 ms | 6.9 ms | ↓ 88% |
| Idle latency | 5.79 ms | 5.91 ms | ≈ flat |
| Full-load throughput | 823 Mbps | 581 Mbps | −29%* |
* trade-off: enabling cake costs ~29% peak throughput (4-core soft-forward shaping overhead) in exchange for deterministic full-load latency; both still far above typical daily use.
Zwei Wege zum lags-freien Netz
A. Nur Software — SQM auf dem vorhandenen OpenWrt-Router (sinnvoll bis ~300–500 Mbit/s
auf MT7621-Klasse). B. SQM-fähige Hardware — stärkere CPU, siehe unser
Router-Portal (EN). Schnelltest: SQM aktivieren, den
Bufferbloat-Test wiederholen und top beobachten — CPU unter ~70 % bleibt,
CPU an 100 % wechselt zu B.
Wie NetSteer das automatisiert
NetSteer erkennt fehlende Pakete (sqm-scripts + cake), wählt das Preset zur erkannten Bandbreite und schreibt genau diese Einstellungen — mit echtem A/B-Vergleich: erst Basislinie bei AUS, dann der gemessene Gewinn. Ist die Leitung bereits gut, meldet NetSteer „flach“, und das ist ehrlich gemeint.
Weiterlesen: RPS/IRQ auf allen Kernen (EN) und Fullcone NAT (EN).
FAQ
Welche Geschwindigkeit trage ich in den SQM-Einstellungen ein?
Die gemessene Bandbreite, nicht die des Tarifs. Zeigt ein Test abends 912/47 Mbit/s bei einem 1000/50-Tarif, tragen Sie etwa 85-90 % davon ein (rund 800/42) — Reserve für Protokoll-Overhead. Zu hoch eingetragene Werte sind der häufigste Grund, warum SQM scheinbar nichts bringt.
Welches CAKE-QoS-Preset für Gaming?
Beginnen Sie mit piece_of_cake (Standard): bester Latenz-Durchsatz-Kompromiss für normalen Hausverkehr. diffserv4 lohnt sich bei VoIP oder wenn DSCP-Prioritäten genutzt werden sollen, kostet aber etwas mehr CPU. Besteffort spart Rechenleistung auf sehr schwachen CPUs.
Gibt es einen Nachteil durch SQM?
Ja — CAKE tauscht Spitzen-Durchsatz gegen Latenz. Auf unserem 4-Kern-NanoPi-R5C-Prüfstand sank der Durchsatz um etwa 29 %, während die Latenz unter Volllast um 87 % fiel. Für Gaming und Anrufe ist dieser Tausch fast immer wert.