Andere/Übergreifend Bufferbloat, wer, wie, was, wieso, weshalb, warum

[0-8-15 User]

@B3CKS, wenn ich innerhalb meines Heimnetzwerks einen Flaschenhals erzeuge, indem ich die Verbindungsgeschwindigkeit via ethtool von 1 Gbit/s auf 100 Mbit/s reduziere, dann verschlechtern sich bei mir die Latenzen unter Last (sowohl im Down- als auch im Upload):

--- 8.8.8.8 ping statistics ---
rtt min/avg/max/mdev = 46.649/421.287/741.135/220.519 ms

--- 8.8.8.8 ping statistics ---
rtt min/avg/max/mdev = 47.539/77.736/87.879/12.670 ms

Hier läuft noch ein 4K twitch Stream im Hintergrund.

Ungünstig, sofern er dazu führt, dass die Latenzen im Leerlauf dadurch ansteigen.

Mit den Bufferbloat Tests und Ping Tests habe ich festgestellt, dass Kabel nichts für Power User

Wobei man auch nicht dem Trugschluss aufliegen sollte, dass Bufferbloat beim Gaming ohne nennenswerte Hintergrundlast eine Rolle spielen würde, denn Bufferbloat entsteht erst dann, wenn die Leitung in die Nähe der maximalen Auslastung kommt, was bei reinem Gaming quasi nie vorkommt.

 

[pufferueberlauf]

Nope, der Sourceforge Test bot das auch. Leider wurde das Ding wieder eingestampft

Das ist jetzt nicht im Widerspruch zu meiner Aussage, aber ja den Test hatte ich wieder verdrängt, und auch der thinkbroadband Speedtest hat wenn man auf den gruenen "Analysis" Button klickt einen "Latency Performance" Bufferbloat Plot, ändert aber nichts daran, dass lange Zeit der dslreports Test der einzig weithin verfügbare war (soweit ich weiss waren die die ersten, leider ist da die Infrastruktur inzwischen ein bisschen verrottet).

Ergänzung (20. März 2022)

indem ich die Verbindungsgeschwindigkeit via ethtool von 1 Gbit/s auf 100 Mbit/s reduziere

Das ist nur der erste Teil der notwendigen Massnahmen:
1) den Flaschenhals in den Bereich des Netzes verlagern ueber den man selber Kontrolle hat
2) und dann dort mit kompetentem AQM dafuer sorgen, dass die Puffer nicht zu gross und/oder zu schlecht verwaltet werden.

Der Ethtooltrick erschlaegt erstmal nur den ersten Punkt... Wenn der Router mit BQL arbeitet und fq_codel als Standard-Qdisc, dann kann dieser Trick im Uplink schon helfen (aber nur wenn der Upstream >= 100 Mbps ist) aber im Downstream nur bedingt...

Wobei man auch nicht dem Trugschluss aufliegen sollte, dass Bufferbloat beim Gaming ohne nennenswerte Hintergrundlast eine Rolle spielen würde, denn Bufferbloat entsteht erst dann, wenn die Leitung in die Nähe der maximalen Auslastung kommt, was bei reinem Gaming quasi nie vorkommt.

Ja wenn man garantieren kann, dass der eigene Link niemals gesättigt wird*, braucht es i.d.R. keine Massnahmen, nur sollte man IMHO nicht vergessen, dass auch bereits kurzfristige Sättigung zu "Rucklern" führen kann, und die ist deutlich wahrscheinlicher als dauerhafte Volllast. Man denke nur an Geräte die automatische Updates beziehen, bzw. in Netzen mit mehr als dem Gamer im Beispiel wird es schwieriger alle Aktivitaet so zu koordinieren, dass Saettigung ausgeschlossen werden kann. Persönlich wuerde ich so etwas lieber etwas strikter kontrollieren statt darauf zu bauen, dass ich den kompletten Traffic meines Netzes ausreichend gut vorhersagen/steuern kann, aber das ist natuerlich eine subjektive Entscheidung, die weder besser noch schlechter ist als die Alternative.


*) Das ist natuerlich so in dieser Form eine inkorrekte Beschreibung, weil der Internetlink ist zu jedem Zeitpunkt entweder 100% ausgelastet (wenn gerade ein Packet gesendet wird) oder zu 0%, die wichtigere Frage ist, wie viele Pakete (welcher Groesse) in der Warteschlange vor einem Paket liegen, welches gerade beim Router einlaeuft, d.h. kommt ein neues Paket erst dann rein wenn das vorherige vollstaendig transferriert wurde oder noch waehrend dessen Transfer. Bei einem Heimrouter kann das z.B. dann passieren, wenn parallele Nutzer gleichzeitig ueber LAN und WLAN das Internet nutzen... ist aber Korinthen-Kackerei weil es herzlich egal fuer fast ale Anwendungen ist, solange die Verzoegerung durch diesen Effekt nur klein genug bleibt.

 

[0-8-15 User]

In der Download Richtung muss man in der Tat den Shaper so einstellen, dass er spürbar unter der echten Flaschenhalsrate liegt ... 85-90% der echten Flaschenhalsrate ist oft ein guter Richtwert

Bei meinem SVDSL Anschluss der Telekom genügt es, knapp 5 % der Nettodatenrate zu opfern, um mit den Standardeinstellungen von FQ-CoDel jeglichen Bufferbloat im Keim ersticken zu können.

Das ist nur der erste Teil der notwendigen Massnahmen

Deshalb bezweifel ich auch, dass man mit den Werksmitteln einer FRITZ!Box Bufferbloat in den Griff bekommt.

nur sollte man IMHO nicht vergessen, dass auch bereits kurzfristige Sättigung zu "Rucklern" führen kann

Richtig, nur habe ich den Eindruck, dass viele* der grundsätzlich falschen Vorstellung erliegen, dass Bufferbloat die Leitung lastunabhängig negativ beeinflussen würde.

*) Stichwort: "gamerunfreundliches" Internet / Faktoren?

 

[pufferueberlauf]

Bei meinem SVDSL Anschluss der Telekom genügt es, knapp 5 % der Nettodatenrate zu opfern, um mit den Standardeinstellungen von FQ-CoDel jeglichen Bufferbloat im Keim ersticken zu können.

Ingress shaping ist immer eine Heuristik/Approximation, je mehr Flows gleichzeitig aktiv sind desto unpraeziser wird die Kontroll und desto wahrscheinlicher wird es, dass es zu Rueckstau in die Puffer auf der ISP Seite kommt, d.h. das notwendige Opfer haengt von aktuellen Traffic-Verhalten ab. Cake im ingress Modus passt seine "Schaerfe" automatisch an und greift da durch, was dazu fuehrt, dass ein geringes Bandbreitenopfer notwendig ist (allerdings etwas auf Kosten der Durchsatz-Fairness, im Ingress-Modus verrechnet Cake auch die Gedroppten/Gemarkten Packete gegen den Kapazitaetsanteil eines Flows)... Soll heissen, ich glaube Dir wenn Du schreibst "jeglichen Bufferbloat im Keim ersticken" aber weise darauf hin, dass das stark vom Traffic abhängt...

Deshalb bezweifel ich auch, dass man mit den Werksmitteln einer FRITZ!Box Bufferbloat in den Griff bekommt.

Die FBs setzen nicht nur einen Traffic-Shaper ein, sondern initiieren auch noch irgendwelche Qdiscs, allerdings, wenn ich mich recht erinnere, keine von denen die im Standard-Kernel vorliegen. Mein Verdacht ist, dass die dadurch die Latenz-unter-Last schon auch "einbremsen" allerdings erwarte ich keine mit HTB+fq_codel/cake ebenbuertige Performance.

Richtig, nur habe ich den Eindruck, dass viele* der grundsätzlich falschen Vorstellung erliegen, dass Bufferbloat die Leitung lastunabhängig negativ beeinflussen würde.

+1; wobei es glücklicherweise halt auch so ist, dass in der Situation traffic-Shaper+kompetentes AQM ebenfalls keine negative Auswirkung auf den Link haben ... Wie sagt der Angelsachse? " Better save than sorry".

 

[0-8-15 User]

aber weise darauf hin, dass das stark vom Traffic abhängt...

Ich bin offen für Vorschläge, wie ich eine Last erzeuge, die meinen Shaper in die Knie zwingt. 😉

was dazu fuehrt, dass ein geringes Bandbreitenopfer notwendig ist

Ich sollte mich mal hinsetzen und die Flent Analyse aus #8 mit Cake wiederholen.

 

[pufferueberlauf]

Ich bin offen für Vorschläge, wie ich eine Last erzeuge, die meinen Shaper in die Knie zwingt. 😉

Je weniger responsiv die flows werden, bzw. je mehr das werden desto problematischer wird es.... also sollte ein flent test mit sagen wir 100 flows das Problem aufzeigen... oder halt 500...

 

[B3CKS]

Bei meinem SVDSL Anschluss der Telekom genügt es, knapp 5 % der Nettodatenrate zu opfern, um mit den Standardeinstellungen von FQ-CoDel jeglichen Bufferbloat im Keim ersticken zu können.

Deshalb bezweifel ich auch, dass man mit den Werksmitteln einer FRITZ!Box Bufferbloat in den Griff bekommt.

Diese Einstellung drücken den Download um ca. 5-10Mbit. Das macht es schon Bufferbloat freudiger. Das habe ich mal getestet. Allerdings startet der Router bei jeder Einstellung neu und der Provider denkt beim 10ten Mal, dass du Probleme hast und fängt auch an zu drosseln. Aber es funktioniert bei mir.

 

[riversource]

Diese Einstellung drücken den Download um ca. 5-10Mbit. Das macht es schon Bufferbloat freudiger.

Sicher? Weil diese Einstellungen drücken ja die physikalische Geschwindigkeit, und nicht die auf Protokollebene.

Das Problem ist doch, dass die Box die Daten nicht los wird, weil die physikalische Verbindung ausgelastet wird. Also nimmt man sowas wie QoS, um vorher auf Protokollebene dafür zu sorgen, dass die physikalische Verbindung nie an die Grenze getrieben wird. Wenn ich nun die physikalische Geschwindigkeit reduziere, dann verlagere ich den Arbeitspunkt, aber ich löse das Problem nicht.

 

[B3CKS]

Sicher? Weil diese Einstellungen drücken ja die physikalische Geschwindigkeit, und nicht die auf Protokollebene.

Das Problem ist doch, dass die Box die Daten nicht los wird, weil die physikalische Verbindung ausgelastet wird. Also nimmt man sowas wie QoS, um vorher auf Protokollebene dafür zu sorgen, dass die physikalische Verbindung nie an die Grenze getrieben wird. Wenn ich nun die physikalische Geschwindigkeit reduziere, dann verlagere ich den Arbeitspunkt, aber ich löse das Problem nicht.

Ja, auch. Meiner Meinung nach macht das die FritzBox indem man die Priorisierung benutzt ( QoS ). Das soll laut AVM für reibungslosen Datentransfer für bestimmte Anwendungen sorgen.

Das Andere sorgt dafür, dass deine DSL unter dem was bei dir ankommt gedrosselt wird, meines Erachtens. Bei mir von 114MBit auf 109Mbit.
Das verschafft dir Luft und selbst wenn deine Leitung am Anschlag steht bleibt DSL halbwegs konstant ohne langsam zu werden, weil der Downloadkanal(e) verstopft ist.

Und Pakete gehen eigentlich nicht verloren oder hängen irgendwo fest, wenn ich das richtig sehe und verstehe.

 

[riversource]

Das Andere sorgt dafür, dass deine DSL unter dem was bei dir ankommt gedrosselt wird, meines Erachtens. Bei mir von 114MBit auf 109Mbit.
Das verschafft dir Luft und selbst wenn deine Leitung am Anschlag steht bleibt DSL halbwegs konstant ohne langsam zu werden, weil der Downloadkanal(e) verstopft ist.

Ja, der Sync reduziert sich durch die Einstellung, weil SNR erhöht wird. Aber ich verstehe noch nicht, warum deshalb die Download Kanäle weniger verstopfen. Das wäre ja nur der Fall, wenn irgendwo in der Infrastruktur ein Bottleneck bei 112 MBit/s oder sowas wäre. Kann natürlich sein, ist aber unwahrscheinlich.
Wenn dein DSL Anschluss das Bottelneck ist - und das wird in der Mehrheit der Fälle so sein - dann verstopft die Leitung eben schon bei 109 MBit/s und nicht erst bei 114. Aber ansonsten ändert sich nichts.

Meines Erachtens kann diese Einstellung kein Traffic Shaping ersetzen, wie es oben beschrieben wird.

 

[pufferueberlauf]

Diese Einstellung drücken den Download um ca. 5-10Mbit. Das macht es schon Bufferbloat freudiger.

Das ist zwar nicht auszuschliessen, aber nicht sonderlich konsistent... Der Traffic Shaper im BNG wird immer mit dem tatsächlichen Sync abgeglichen, in sofern sollte es keinen Unterschied machen ob Dein Link mit 116 oder 100 Mbps synct. Kann sein, dass AVM mit den Schiebern auch noch anderes umsetzt als nur die Sync-Parameter zu beeinflussen, aber das erscheint mir nicht sonderlich wahrscheinlich. Wie gesagt um Bufferbloat zu bekämpfen braucht es zwei Dinge, 1) den Flaschenhals unter eigener Kontrolle und dann 2) kompetentes AQM um das Problem tatsächlich zu lösen.

 

[B3CKS]

Das ist zwar nicht auszuschliessen, aber nicht sonderlich konsistent... Der Traffic Shaper im BNG wird immer mit dem tatsächlichen Sync abgeglichen, in sofern sollte es keinen Unterschied machen ob Dein Link mit 116 oder 100 Mbps synct. Kann sein, dass AVM mit den Schiebern auch noch anderes umsetzt als nur die Sync-Parameter zu beeinflussen, aber das erscheint mir nicht sonderlich wahrscheinlich. Wie gesagt um Bufferbloat zu bekämpfen braucht es zwei Dinge, 1) den Flaschenhals unter eigener Kontrolle und dann 2) kompetentes AQM um das Problem tatsächlich zu lösen.

Alle meine Tests haben ergeben, dass die Einstellungen, die ich beschrieben habe bei mir zum Besten Ergebnis führen A+. Alles andere erzeugt wieder Bufferbloat.

Aber ich bin für alles offen. Wenn du das ein wenig Aufschlüsseln könntest (Traffic Shaper im BNG, AQM) unter Windows, wäre ich dir sehr dankbar. Ich hab ein wenig gegoogelt und mir einiges bei Wikipedia durchgelesen aber... .

LG

 

[pufferueberlauf]

Alle meine Tests haben ergeben, dass die Einstellungen, die ich beschrieben habe bei mir zum Besten Ergebnis führen A+. Alles andere erzeugt wieder Bufferbloat.

Da gibt es eigentlich nur zwei mögliche Erklärungen:
1) wenn die Schieber auf "maximale Performance" stehen akkumuliert Dein Link viele Fehler (CRC Fehler und oder G.INP Retransmissionen) die bei der EInstellung "maximale Stabilitaet" erfolgreich unterdrueckt/verhindert werden, weshalb Dein Link besser funktioniert
2) AVM macht bei der Einstellung "maximale Stabilitaet" etwas mehr als die Beschriftung der Schieber erwarten laesst.

Traffic Shaper im BNG

Die meisten ISP verlassen sich nicht darauf die vertraglichen Maximalraten ueber den Sync auf der DSL Strecke zu implementieren. Schon auch weil DSLAMs/MSANs im wesentlichen L2-Switche (aehnlich einem Ethernet-Switch) sind mit etwas exotischen Ports zum Kunden hin, und Switche sind unter Volllast kein echter Spass (gerade wenn wie bei einem DSLAM aller Traffic durch denselben Uplink-Port fliessen muss). Und bei Mitbewerbern die Zwischenprodukte vom Leitungsbetreiber beziehen (z.B. O2 ueber L3-BASE der Telekom) haben die schlicht gar keine Moeglichkeit den Sync zu beeinflussen. Deshalb brauchen die ISPs andere Optionen um die Raten auf das vertraglich vereinbarte festzuzurren (muessen die natuerlich nicht, koennten auch andere Vertraege anbieten deren Preise nicht nach Geschwindigkeit gestaffelt sind, macht nur keiner). Und am besten ist dafuer das naechste echte IP-Geraet geeeiget. Bei der Telekom ist das das Broadband Network Gateway, kurz BNG, bei O2 ist das wohl der PoP. Da wird dann die Geschwindigkeit begrenzt, entweder mit dummen Policern (alles was instantan ueber der vertraglichen Rate liegt wird gedroppt, ziemlich drastisch) oder mit etwas intelligenteren Traffic-Shapern (die erlauben eine kleine Warteschlange so dass der reinkommende Traffic ueber eine gewissse Zeit aggregiert nicht ueber der vertraglichen Rate liegen kann, aber kurze Schwankungen werden "abgefedert"). Weil in einem PoP oder BNG mehrere Tausend Kundeanschluesse terminiert werden versuchen ISPs da mit so wenig Aufwand pro Paket/Warteschlange durchzukommen, weil performantere Hardware da schnell teuer wird, weshalb ISPs meist auf AQM verzichten (von kompetentem AQM ganz zu schweigen).

Wenn Du jetzt einen Bufferbloat-Test machst, misst Du, bei einem halbwegs kompetenten ISP, i.d.R. die Größe der im Traffic-Shaper konfigurierten Warteschlange und die Qualitaet dessen Queue-Verwaltung.
Hier mal ein Beispiel fuer das was O2 bei mir macht
http://www.dslreports.com/speedtest/70517017
(In der Rubrik "Grades" mal auf die Links unter dem Bufferbloat Plot klicken: Idle, Downloading, Uploading). Im Download sieht man ein Saegezahnmuster von ~40ms bis ~80ms, im Upload sieht man eine Baseline bei ca. 50ms mit periodischen Spikes in den 300er Bereich (aber das ist ein Artefakt meines Browsers).
Mittelwerte:
Idle: 32ms
Downloading: 57ms
Uploading: 56ms
Das ist jetzt nicht toll, aber um Laengen besser als noch vor ein paar Jahren.
Mit kompetentem AQM (im Router, der Endhost, egal mit welchem Betriebssystem weiss davon nichts) sieht das so aus:
https://www.dslreports.com/speedtest/70517044
Mittelwerte:
Idle: 24ms
Downloading: 27ms
Uploading: 43ms
(Wobei Mittelwerte fuer Latenzverteilungen nicht sonderlich gut geeignet sind, aber das ist die Statistik die der Test vorgekaut liefert).

Als Referenz bietet sich: https://www.bufferbloat.net/projects/ an

 

[0-8-15 User]

also sollte ein flent test mit sagen wir 100 flows das Problem aufzeigen...

Stimmt, da war ich wohl bisher einfach zu knausrig mit der Anzahl der parallelen Flows!

(codel_xx bzw. cake_xx bedeutet, dass jeweils [100 - xx] % der Nettodatenrate geopfert wurde)

 

[pufferueberlauf]

Cake war mit dem

ingress

Keyword? Ich finde man sieht, a) cake ist eine Spur besser (was Raten- ud Latenzvarianz angeht) und b) fq_codel und cake profitieren beide beim Ingress-Shaping von etwas hoehere Raten-Opfern, allerdings sing 100 parallele aktive Flows jetzt keine normale Last mehr, ausser vielleicht wenn man gerade die neueste Linux Distribution per Bit-Torrent zieht und verteilt, oder welche Dateien auch immer die hoechste instantane Nachfrage ausloesen...
Ich bin aber ganz ehrlich erstaunt wie gering der Effekt ist, allerdings ist ja auch die Latenz im "nativen" Fall jetzt nicht sooo garstig, wie man das noch vor ein paar Jahren gesehen hat. (Ich interpretiere "naive" als kein Shaper in Deinem Router aktiv).

 

[0-8-15 User]

Cake war entsprechend der Inbound configuration under linux Anleitung von bufferbloat.net konfiguriert.

Ich interpretiere "naive" als kein Shaper in Deinem Router aktiv

Richtig.

Ich finde man sieht, a) cake ist eine Spur besser und b) fq_codel und cake profitieren beide beim Ingress-Shaping von etwas hoehere Raten-Opfern

Seh ich genauso.

 

[pufferueberlauf]

Cake war entsprechend der Inbound configuration under linux Anleitung von bufferbloat.net konfiguriert.

Was sagt der Output von
tc -s qdisc
fuer das IFB?

Ergänzung (21. März 2022)

Cake war entsprechend der Inbound configuration under linux Anleitung von bufferbloat.net konfiguriert.

Was sagt der Output von
tc -s qdisc
fuer das IFB, ingress oder egress?

 

[0-8-15 User]

IFB, ingress oder egress?

Weder noch? Man schnappt sich ja einfach die Pakete, die auf eno1 ankommen und biegt sie auf das ifb um:

tc qdisc add dev eno1 handle ffff: ingress
tc filter add dev eno1 parent ffff: matchall action mirred egress redirect dev ifb4eno1

Auf welchem man dann wie gehabt die Outbound configuration under linux anwenden kann:

tc qdisc add dev ifb4eno1 root cake bandwidth 267mbit besteffort

Was sagt der Output von
tc -s qdisc

qdisc ingress ffff: dev eno1 parent ffff:fff1 ----------------
 Sent 5106867979 bytes 3477173 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8002: dev ifb4eno1 root refcnt 2 bandwidth 267Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0
 Sent 5222049506 bytes 3469260 pkt (dropped 7825, overlimits 5260399 requeues 0)
 backlog 167166b 111p requeues 0
 memory used: 863680b of 13350000b
 capacity estimate: 267Mbit
 min/max network layer size:           60 /    1506
 min/max overhead-adjusted size:       60 /    1506
 average network hdr offset:           14

                  Tin 0
  thresh        267Mbit
  target            5ms
  interval        100ms
  pk_delay       5.39ms
  av_delay       5.21ms
  sp_delay       5.13ms
  backlog       167166b
  pkts          3477196
  bytes      5233999682
  way_inds        16956
  way_miss          180
  way_cols            0
  drops            7825
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len         33132
  quantum          1514

 

[pufferueberlauf]

Ah, danke, pack doch mal ingress als keyword zu Deiner cake Invokation auf ifb4eno1 dazu und wiederhole Deinen Test (sowie overhead 26 mpu 68) und dann wiederhole noch mal den 100 Flow test mit 100, 95, 95 und 85% Shapern....
Also:
tc qdisc add dev ifb4eno1 root cake bandwidth 267mbit besteffort ingress overhead 26 mpu 68

Das ingress Keyword sorgt dafuer, dass cake nicht die Egress-Rate sondern die Ingress-Rate mit der Pakete in die Warteschlange aufgenommen werden kontrolliert was dazu fuehren sollte, dass cake seine Drop/Mark-Aggressivitaet automatisch anpassen sollte wenn mehr Flows aktiv werden. Waere interessant zu sehen ob das bei Dir in der Praxis so funktioniert wie in der Threorie beschrieben....

 

[0-8-15 User]

pack doch mal ingress als keyword zu Deiner cake Invokation auf ifb4eno1 dazu und wiederhole Deinen Test

Im Alltag verwende ich FQ-CoDel und verzichte dabei auf ca. 3 % der Nettodatenrate:

sowie overhead 26 mpu 68) und dann wiederhole noch mal den 100 Flow test mit 100, 95, 95 und 85% Shapern....

Mein Modem zeigt einerseits die Bruttodatenrate nicht an und andererseits wollten wir ja der Frage nachgehen, welchen Anteil der Nettodatenrate man opfern muss, um Bufferfloat bei hoher Last in den Griff zu bekommen, deshalb habe ich die Shaper so eingestellt, dass mit iperf3 -c <testserver> -4 -R -P1 jeweils 95 %, 90%, bzw. 85 % der Nettodatenrate erreicht werden.