Dein Router hat ein Wartezimmer ohne Obergrenze, und wer drin sitzt, wartet weiter. Deshalb springt dein Ping, sobald jemand einen Upload startet.
Kurz gesagt
Bufferbloat ist eine übermäßige Verzögerung durch Puffer im Netz, die zu groß sind und oft voll [1]. Sie zeigt sich als Ping, der stark steigt, solange die Leitung ausgelastet ist, obwohl Bandbreite reichlich da ist [5]. Das Gegenmittel sind kurze Warteschlangen durch aktives Queue-Management (AQM), etwa CoDel und FQ-CoDel [2][3][4]. Auf einem Heimrouter heißt das meist Smart Queue Management (SQM) mit einem Shaper knapp unter der echten Leitungsgeschwindigkeit [5]. Unsere Einschätzung: Wenn dein Spiel nur laggt, solange die Verbindung ausgelastet ist, teste auf Bufferbloat, bevor du für einen schnelleren Tarif zahlst.
So funktioniert’s
- Die Warteschlange. Ein Router puffert Pakete, wenn mehr ankommen, als die Leitung senden kann. Gettys und Nichols schreiben, große Puffer seien ohne ausreichende Überlegung überall im Internet eingebaut worden und machten die Überlastvermeidung von TCP wirkungslos [1].
- Die Fehldiagnose. Sie ergänzen, die langen Verzögerungen würden oft der Netzüberlastung zugeschrieben, was zu falschen Lösungen führt [1]. Mehr Bandbreite leert keine Warteschlange, die immer voll ist.
- Was du merkst. OpenWrt beschreibt es als besonders sichtbar, wenn eine Verbindung stark mit Downloads oder Uploads belegt ist. Die Latenz steigt, was VoIP, Videochat und Online-Spiele beeinträchtigt [5].
- AQM. RFC 7567 empfiehlt nachdrücklich, aktives Queue-Management in Netzgeräten zu testen, zu standardisieren und breit einzusetzen [2]. CoDel steuert die überschüssige Verzögerung, die Bufferbloat erzeugt, misst, wie lange Pakete warten, und braucht in normalen Internet-Umgebungen keine Konfiguration [3].
- Flow Queueing. FQ-CoDel mischt Pakete vieler Flüsse und verringert Head-of-Line-Blocking durch stoßweisen Verkehr. Es schützt Verkehr mit niedriger Rate wie DNS, Web und Videoanrufe [4]. Es ist ein experimenteller RFC und steckt als fq_codel im Linux-Hauptkernel [4]. RFC 8289 sagt Implementierern, diesen Mehrfach-Queue-Ansatz zu bevorzugen [3].
- SQM auf dem Router. OpenWrts SQM verbindet Scheduling je Fluss, AQM und Traffic Shaping. Es braucht Rechenleistung und funktioniert nicht mit Flow Offloading [5]. Die Anleitung setzt Download- und Upload-Limit auf 90 % der in einem ruhigen Netz gemessenen Geschwindigkeit, wählt cake oder fq_codel als Queue-Disziplin und lässt dich den Speedtest wiederholen [5]. Unsere Lesart: Ein Shaper knapp unter der Leitungsgeschwindigkeit verlegt die Warteschlange in den Router, wo das AQM sie steuern kann.
Ein Praxisbeispiel
Mach einen Speedtest, der die Latenz während Download und Upload ausgibt. OpenWrt nennt dafür Waveform und Speedtest [5]. Ohne so einen Test lässt du ping laufen (siehe unser Eintrag zu Ping und Jitter), während ein großer Upload läuft. In OpenWrts Anleitung zeigt das Beispiel eines Nutzers an einer Kabelleitung mit 500/35 Mbit +18 ms (Download) und +38 ms (Upload) ohne SQM und +0 ms mit cake bei 90-%-Limits [5]. Das ist das Ergebnis eines Nutzers an einer Leitung, kein Versprechen für deine. Ob unser Router eine Smart-Queue-Funktion bietet: nicht erfasst. Unser Inventar (Stand 14. bis 16. Okt. 2026) führt einen UniFi-Router mit Firewall ohne seine Queue-Einstellungen, deshalb zeigen wir keine Messwerte unseres eigenen Netzes.
Prüfliste
- Miss den Ping im Leerlauf und dann noch einmal bei vollem Upload und vollem Download [5].
- Miss die Leitungsgeschwindigkeit zuerst, wenn das Netz ruhig ist [5].
- Prüfe, ob dein Router SQM, Smart Queues oder fq_codel anbietet [4][5].
- Setze den Shaper auf etwa 90 % der gemessenen Geschwindigkeit und teste erneut [5].
- Schalte Flow Offloading ab, wo der Router es für SQM verlangt [5].
- Erhöhe das Limit in kleinen Schritten, bis die Latenz zu steigen beginnt, und geh dann einen Schritt zurück [5].
- Notiere Einstellungen und Testergebnisse mit Datum.