Unitymedia Bufferbloat eliminieren für Streaming auf Twitch

[MKmasta]

Hi,

aktuell nutze ich das TC4400 mit der 6490.

Jetzt habe ich beim Streaming zu Twitch einen Bufferbloat und frage mich ob ich den mit openWRT oder auch sonstigem kram wegbekommen könnte?!

Hier mal die Sachlage:
https://abload.de/img/streammhkyk.png

Bin noch neu in dem Thema. Die rote Makierung = Streaming mit 6mbits upload bei gleichzeitigem Gameplay.

Was kann ich jetzt tun? Ich habe gehört es gibt auch Scripte für das TC4400 die dabei helfen? Bin wie gesagt noch ein totaler Anfänger in dem Themenbereich und sehr dankbar über jeden Tipp

 

[addicted]

Relevant wäre, welchen Tarif Du gebucht hast und ob Du in Speedtests jederzeit diese Datentransferrate auch erreichst. Wenn nämlich die Leitung noch nicht voll ist, fließt auch nix in den Buffer.

 

[MKmasta]

Relevant wäre, welchen Tarif Du gebucht hast und ob Du in Speedtests jederzeit diese Datentransferrate auch erreichst. Wenn nämlich die Leitung noch nicht voll ist, fließt auch nix in den Buffer.

Business 200/20

Der "Bloat" beginnt aber bereits bei minimalem upload von 6mbits. Die Speedtests sind jederzeit rel. ähnlich.

 

[addicted]

Erklär mir bitte mal, was genau Du mit Bufferbloat meinst. Beschreib mal, was das ist und wie es dazu kommt, in Deinen Worten.

 

[sch4kal]

Glaube nicht, dass das Bufferbloat ist. Was sagt denn der Bufferbloat-Test ? http://www.dslreports.com/speedtest

 

[Wechseler]

Relevant wäre, welchen Tarif Du gebucht hast und ob Du in Speedtests jederzeit diese Datentransferrate auch erreichst. Wenn nämlich die Leitung noch nicht voll ist, fließt auch nix in den Buffer.

Das ist bei HFC so nicht korrekt. Das Kabel-Modem wartet auf die Zuteilung von Rückweg-Zeitschlitzen vom CMTS unabhängig von der genutzten Datenrate und das verursacht zwangsläufig Wartezeiten. Für das Drosseln des Uploads ist das Kabelmodem zudem selbst zuständig, so daß sich die Situation bei Ausnutzung der gebuchten Datenrate auch nicht nennenswert verändert.

Weg bekommt man nur das nur mit einem Technologiewechsel. Das Breitbandkabel ist nur sehr beschränkt "sendefähig".

 

[rv112]

Mit gutem QoS im Router kann man das Problem jedoch auch minimieren.

 

[Wechseler]

Mit gutem QoS im Router kann man das Problem jedoch auch minimieren.

Das Problem, daß das Kabelmodem auf einen EuroDOCSIS-3.0-Zeitschlitz zum Senden warten muß, kann ein Router dahinter mit noch so tollem QoS nicht minimieren. Und gewartet werden muß um so öfter, je mehr gesendet wird - bei HFC völlig unabhängig von der gedeckelten Tarif-Übertragungsrate, da Shared Medium, denn die anderen 1000 Kunden im Segment wollen auch mal drankommen.

Die Kapazität im Rückkanal ist vergleichsweise knapp und das macht sich in der vom Threadersteller geposteten Jitter-Grafik leider genau so bemerkbar. Das ist nicht vergleichbar mit VDSL, wo man bis zu 40 Mbps für sich alleine hat und sich erst die nahezu latenzfreie symmetrische Glasfaserstrecke (mit weniger ausgelasteter Uplink-Richtung) teilen muß. Dort kann ein Router natürlich Traffic geschickt unter die 40 Mbps Leitungsgeschwindigkeit drosseln, um die Puffer möglichst leer zu halten. Eine solche "Leitungsgeschwindigkeit" gibt es bei HFC aber gar nicht. Entweder der Rückweg ist gerade zufällig frei oder dein Päckchen landet im Puffer.

So toll das Kabel auch zum Gigabit-Saugen ist: Wer selbst hochloaden will, ist bei Koax leider falsch.

 

[robert_s]

Und gewartet werden muß um so öfter, je mehr gesendet wird

Falsch gedacht, das Gegenteil ist der Fall. Je mehr Grants ein Kabelmodem bekommt, desto zeitlich dichter liegen die zugeteilte Zeitschlitze im Mittel beeinander.

So toll das Kabel auch zum Gigabit-Saugen ist: Wer selbst hochloaden will, ist bei Koax leider falsch.

Dieses Fazit geben weder Betrachtung noch Realität her. Und einen Anstieg der Latenz um max. 5ms bei gleichzeitigem Upload halte ich für vernachlässigbar gering. Möglicherweise sind die in diesem Fall auch der Kombination Modem + Router als getrennte Geräte geschuldet.

Aber zeige gerne mal eine Grafik von einem VDSL-Anschluss, der sich bei 6Mbit/s Upload völlig unbeeindruckt zeigt. Ich habe da auch gewisse Zweifel.

@MKmasta: Die Kombination Modem + Router als separate Geräte erlaubt nicht unbedingt für DOCSIS optimiertes Buffer Management, ein IAD kann das ggf. besser.

 

[Wechseler]

Falsch gedacht, das Gegenteil ist der Fall. Je mehr Grants ein Kabelmodem bekommt, desto zeitlich dichter liegen die zugeteilte Zeitschlitze im Mittel beeinander.

Wenn die Kapazität vorhanden ist. Sonst haut das nicht hin. Ich bin beispielsweise in einem Segment, wo man bis zu 40 ms auf die Sendegenehmigung wartet. Daß die maximal buchbare Upstream-Rate für alle Kunden 8 Mbps beträgt, ist zwar ein Eingeständnis, ändert an dem Kapazitätsproblem grundsätzlich nichts.

Dieses Fazit geben weder Betrachtung noch Realität her. Und einen Anstieg der Latenz um max. 5ms bei gleichzeitigem Upload halte ich für vernachlässigbar gering. Möglicherweise sind die in diesem Fall auch der Kombination Modem + Router als getrennte Geräte geschuldet.

Was genau soll der Modem-Router machen, wenn er ständig Päckchen für Twitch bekommt, aber gerade nicht weiterleiten kann? Sie vorsorglich wegwerfen? Oder doch puffern und ein paar Millisekunden später auf die Reise schicken? Ändert das irgendwas am Jitter?

Aber zeige gerne mal eine Grafik von einem VDSL-Anschluss, der sich bei 6Mbit/s Upload völlig unbeeindruckt zeigt. Ich habe da auch gewisse Zweifel.

Ein DSL-Uplink ist im Verhalten schlicht vorhersagbarer. Wenn eine Leitung mit 40 Mbps Datenrate läuft und gerade idle ist, geht jedes Frame sofort auf die Reise. Darauf kann sich ein QoS-Algorithmus einrichten. Interessant wird es eh erst, wenn Dienste oberhalb der gebuchten Datenrate konkurrieren, aber diese hat das Kundenendgerät komplett unter seiner Kontrolle, da es schlicht keine fremden Konkurrenten um die Leitungskapazität gibt.

Sobald der Glasfaser-Link oder Bitstream-Anbindung überlastet sind, kann man sich den Aufwand natürlich sparen. Daran kann genau wie bei DOCSIS endkundenseitig schlicht nichts tun.

 

[rv112]

Bufferbloat und Jitter entsteht aber auch wenn die Leitung ausgelastet ist. Durchs QoS kann man hier schon etwas Abhilfe schaffen.

 

[robert_s]

Falsch gedacht, das Gegenteil ist der Fall. Je mehr Grants ein Kabelmodem bekommt, desto zeitlich dichter liegen die zugeteilte Zeitschlitze im Mittel beeinander.

Wenn die Kapazität vorhanden ist. Sonst haut das nicht hin. Ich bin beispielsweise in einem Segment, wo man bis zu 40 ms auf die Sendegenehmigung wartet. Daß die maximal buchbare Upstream-Rate für alle Kunden 8 Mbps beträgt, ist zwar ein Eingeständnis, ändert an dem Kapazitätsproblem grundsätzlich nichts.

Die Einschränkung, dass das nur bei überlasteten Segmenten ein Problem ist, hast Du vorher aber verschwiegen, sondern es als ein generelles Problem von "Koax" dargestellt, war nicht der Wahrheit entspricht.

Was genau soll der Modem-Router machen, wenn er ständig Päckchen für Twitch bekommt, aber gerade nicht weiterleiten kann? Sie vorsorglich wegwerfen? Oder doch puffern und ein paar Millisekunden später auf die Reise schicken? Ändert das irgendwas am Jitter?

Soweit ich das verstanden habe, ist der Jitter für Twitch gar nicht relevant (ein Streaming-Dienst, der keine 5ms Jitter verträgt, dürfte auch praxisuntauglich sein), sondern vielmehr, dass sich beim gleichzeitigen Gaming eine erhöhte Latenz zeigte. Dem könnte geschicktes Buffer Management tatsächlich abhelfen. IIRC habe ich sogar schon mal gelesen, dass beim Upstream-Streaming an DOCSIS-Anschlüssen die Latenz tatsächlich sinken kann, weil das ständige Streaming dafür sorgt, dass sdas Kabelmodem regelmäßig Sendeschlitze anfordert, was dann interaktiven Anwendungen zugute kommt. Dann landet das Twitch-Päckchen im Buffer, weil das Gaming-Päckchen den eigentlich dafür angeforderten Zeitschlitz bekommt.

Ein DSL-Uplink ist im Verhalten schlicht vorhersagbarer.

Postulierst Du aber nur. Einen Nachweis aus der Praxis kannst Du offenbar nicht aufbieten.

Mit G.INP im Upstream hat es sich übrigens auch schon wieder mit der "Vorhersagbarkeit", denn evtl. notwendige Retransmissions kannst Du nicht vorhersagen...

 

[sch4kal]

Falsch gedacht, das Gegenteil ist der Fall. Je mehr Grants ein Kabelmodem bekommt, desto zeitlich dichter liegen die zugeteilte Zeitschlitze im Mittel beeinander.

Wenn die Kapazität vorhanden ist. Sonst haut das nicht hin. Ich bin beispielsweise in einem Segment, wo man bis zu 40 ms auf die Sendegenehmigung wartet. Daß die maximal buchbare Upstream-Rate für alle Kunden 8 Mbps beträgt, ist zwar ein Eingeständnis, ändert an dem Kapazitätsproblem grundsätzlich nichts.

Die Einschränkung, dass das nur bei überlasteten Segmenten ein Problem ist, hast Du vorher aber verschwiegen, sondern es als ein generelles Problem von "Koax" dargestellt, war nicht der Wahrheit entspricht.

Was genau soll der Modem-Router machen, wenn er ständig Päckchen für Twitch bekommt, aber gerade nicht weiterleiten kann? Sie vorsorglich wegwerfen? Oder doch puffern und ein paar Millisekunden später auf die Reise schicken? Ändert das irgendwas am Jitter?

Soweit ich das verstanden habe, ist der Jitter für Twitch gar nicht relevant (ein Streaming-Dienst, der keine 5ms Jitter verträgt, dürfte auch praxisuntauglich sein), sondern vielmehr, dass sich beim gleichzeitigen Gaming eine erhöhte Latenz zeigte. Dem könnte geschicktes Buffer Management tatsächlich abhelfen. IIRC habe ich sogar schon mal gelesen, dass beim Upstream-Streaming an DOCSIS-Anschlüssen die Latenz tatsächlich sinken kann, weil das ständige Streaming dafür sorgt, dass sdas Kabelmodem regelmäßig Sendeschlitze anfordert, was dann interaktiven Anwendungen zugute kommt. Dann landet das Twitch-Päckchen im Buffer, weil das Gaming-Päckchen den eigentlich dafür angeforderten Zeitschlitz bekommt.

Ein DSL-Uplink ist im Verhalten schlicht vorhersagbarer.

Postulierst Du aber nur. Einen Nachweis aus der Praxis kannst Du offenbar nicht aufbieten.

Mit G.INP im Upstream hat es sich übrigens auch schon wieder mit der "Vorhersagbarkeit", denn evtl. notwendige Retransmissions kannst Du nicht vorhersagen...

Das Praxisbeispiel siehst du in meiner Signatur...

 

[robert_s]

Das Praxisbeispiel siehst du in meiner Signatur...

Und zwischen 17 und 21 Uhr hast Du auf Twitch gestreamt...?!?

 

[sch4kal]

Das Praxisbeispiel siehst du in meiner Signatur...

Und zwischen 17 und 21 Uhr hast Du auf Twitch gestreamt...?!?

Nein, hatte vergessen dazu zu schreiben das ich von VDSL zu meinem Kabelanschluss jede Nacht von 2 bis ~ 4 Uhr Backups fahre. Von der VDSL-Leitung aus mit fast vollem Upload-Speed (40 Mbits minus ein paar Kbit/s für VoIP QoS).

Die Spikes Nachmittags tauchen täglich auf wo so gut wie keine Last auf der Leitung ist, bin noch näher am Debuggen, scheint aber die Route bis zum ersten Hop zu sein.

 

[robert_s]

Nein, hatte vergessen dazu zu schreiben das ich von VDSL zu meinem Kabelanschluss jede Nacht von 2 bis ~ 4 Uhr Backups fahre. Von der VDSL-Leitung aus mit fast vollem Upload-Speed (40 Mbits minus ein paar Kbit/s für VoIP QoS).

Also obwohl die Leitung nicht "am Anschlag" ist, dennoch ein deutlicher Anstieg von Latenz und Jitter, Latenz um ca. 20ms höher. Damit kann man @Wechseler's Behauptungen ins Reich der Fabeln verweisen.

Interessant wäre freilich, wie der BQM für den Kabelanschluss aussähe, wenn Du dort mal ein derartiges nächtliches Backup fahren würdest. Dann hätte man den direkten Vergleich.

 

[Andreas1969]

Die Spikes Nachmittags tauchen täglich auf wo so gut wie keine Last auf der Leitung ist, bin noch näher am Debuggen, scheint aber die Route bis zum ersten Hop zu sein.

Hier bei meinem Super Vectoring Anschluss tauchen die nicht auf

Und bei meinem Unitymedia Anschluss sieht es deutlich schlechter aus:

 

[rv112]

Ich habe 2 VDSL Anschlüsse, bei denen ebenfalls täglich dieser Anstieg auftaucht, obwohl die Leitungen keinerlei Last haben.

 

[Andreas1969]

Ich habe 2 VDSL Anschlüsse, bei denen ebenfalls täglich dieser Anstieg auftaucht, obwohl die Leitungen keinerlei Last haben.

Komisch, hier ist teils ordentlich Last auf der Leitung, taucht aber nicht auf. Ist das vielleicht von der Region abhängig?

 

[Wechseler]

Nein, hatte vergessen dazu zu schreiben das ich von VDSL zu meinem Kabelanschluss jede Nacht von 2 bis ~ 4 Uhr Backups fahre. Von der VDSL-Leitung aus mit fast vollem Upload-Speed (40 Mbits minus ein paar Kbit/s für VoIP QoS).

Also obwohl die Leitung nicht "am Anschlag" ist, dennoch ein deutlicher Anstieg von Latenz und Jitter, Latenz um ca. 20ms höher. Damit kann man @Wechseler's Behauptungen ins Reich der Fabeln verweisen.

Die Aussagen waren über die VDSL-Strecke getätigt worden. Weder kann ein QoS-Router gammlige Infrastruktur dahinter ausgleichen, noch kann man bei einer Nahezu-Vollauslastung des Upstreams keinen Latenzanstieg erwarten. Wenn also wenig Buffer-Bloat das Ziel ist, muß man die Upload-Geschwindigkeit des Backups drastisch reduzieren.

 

[robert_s]

Die Aussagen waren über die VDSL-Strecke getätigt worden.

Und damit für die Praxis völlig wertlos. Und den Nachweis, dass in der Praxis ein VDSL-Anschluss auf einen 6Mbit/s Upload-Stream mit weniger Latenzerhöhung reagiert als der hier gezeigte DOCSIS-Anschluss, bist Du schuldig geblieben.

 

[Edding]

Ich habe 2 VDSL Anschlüsse, bei denen ebenfalls täglich dieser Anstieg auftaucht, obwohl die Leitungen keinerlei Last haben.

Sieht nach überlasteter Anbindung aus .. typische uhrzeiten dafür und Packet loss ist auch vorhanden..

 

[rv112]

Wohne direkt an der Vermittlungsstelle mit A0 Leitung. Bis zum POP sind es 3km.

 

[sch4kal]

Nein, hatte vergessen dazu zu schreiben das ich von VDSL zu meinem Kabelanschluss jede Nacht von 2 bis ~ 4 Uhr Backups fahre. Von der VDSL-Leitung aus mit fast vollem Upload-Speed (40 Mbits minus ein paar Kbit/s für VoIP QoS).

Also obwohl die Leitung nicht "am Anschlag" ist, dennoch ein deutlicher Anstieg von Latenz und Jitter, Latenz um ca. 20ms höher. Damit kann man @Wechseler's Behauptungen ins Reich der Fabeln verweisen.

Interessant wäre freilich, wie der BQM für den Kabelanschluss aussähe, wenn Du dort mal ein derartiges nächtliches Backup fahren würdest. Dann hätte man den direkten Vergleich.

Siehe mein Nachtrag. Der Spike in der Kabelleitung war ein Testupload von 10GB zu Google Drive, übrigens trotz eingerichtetem QoS (separat für ICMP/ACK Queue und UDP).
Von einer gleichbleibenden, geschweigedenn geringeren Latenz merke ich da aber nix.

 

[boba]

Es werden hier meiner Auffassung nach zwei Sachen durcheinandergebracht.

Der klassische Bufferbloat tritt auf, wenn eine Richtung der Datenverbindung (üblicherweise der upstream) von einem Datenstrom vollständig ausgelastet (gesättigt) ist. In dem Fall sind die Puffer der Netzwerkgeräte/Router gefüllt, die die Pakete von einem Medium mit höherer Geschwindigkeit zu einem Medium mit niedrigerer Geschwindigkeit übertragen. Hat man einen zweiten Datenstrom, z.B. den einer interaktiven Anwendung, werden die Pakete dieses Datenstroms hinten an den gefüllten Puffer angefügt und müssen warten, bis die vorherigen Daten erstmal rausgeschaufelt worden sind. Ist der Upstream durch Datenstrom#1 gesättigt und man macht man einen download (Datenstrom#2), dann müssen die Acknowledgements für den Download die upstream-Puffer durchqueren, die durch Datenstrom#1 gefüllt sind - dadurch verlangsamt sich der Download erheblich. Die Auswirkung dieses Effekts ist deutlich sichtbar: die Latenzen sämtlicher Verbindungen und -Pakete erhöhen sich massiv. Interaktive Verbindungen werden extrem schwammig.

Der zweite Effekt ist die generelle Auslastung des Mediums. Beim shared Medium TV-Kabel werden nicht nur die eigenen, sondern auch die Pakete der anderen übertragen. Je mehr Pakete übertragen werden, desto mehr macht sich das Warten auf Versende-Slots der eigenen Pakete (Jitter) bemerkbar. Der Jitter erstreckt sich auf mehr und mehr Pakete. Die Auswirkung dieses Effekts ist eine moderate Erhöhung der Latenzen sämtlicher Pakete. Messbar, aber wenig fühlbar. Wird das Segment insgesamt überlastet, erhöht sich die Latenz stärker.

Beim OP sehe ich nicht den klassischen Bufferbloat. Der äußert sich viel stärker und vor allem ab dem Zeitpunkt des Einsetzens massiv bei sämtlichen Paketen. Nicht mal so 5ms mehr, sondern das wären eher 40-100ms mehr. Ich sehe da einfach nur eine moderate Erhöhung durch erhöhten Datendurchsatz. Bei 6 mbit/s Auslastung von 20 mbit/s eine Erhöhung um 5ms bei ein paar Ping-Paketen würde ich keinen Bufferbloat ausrufen. Der Bufferbloat würde erst einsetzen, wenn man versuchen würde mit 19-20 mbit/s zu streamen.

Richtiger Bufferbloat bei einer 200/20 Leitung und einer Fritzbox 6490 sieht so aus:

Da habe ich um 18:55 einen Upload mit voller Bandbreite gestartet. Das erhöhte die durchschnittliche Latenz nur auf 33 ms (von durchschnittlich 14 sonst). Um19 Uhr herum habe ich den Transfer auf 750 kbit/s (6000 mbit/s) reduziert, da ist keine Latenzerhöhung zu sehen. Die Minute vor der vollen Bandbreite wiederum, habe ich mit Limit 2000 kbit/s (16000 mbit/s) gefahren - dort war die Latenz auf 20 ms rauf, also schon deutlich höher.

Das ist alles nicht wirklich schlimmes Bufferbloat. Wir haben hier ein ziemlich gutmütiges Netz, würde ich sagen. Früher mit DSL 6000 hätte das spikes von 1000-3000 ms gegeben.
Die gewöhnliche Latenzänderung im Laufe des Tages durch die Auslastung der anderen Teilnehmer im Kabelsegment sieht übrigens in dieser Größenordung aus:

Ist also auch nicht wirklich gravierend. Das hängt allerdings von der Auslastung des eigenen Segments ab. Das kann bei jedem anders aussehen. Ich hatte früher auch schon mal am Wochenende gegen Abend deutlich höhere Kuppen, die gingen teils bis 50 ms rauf.

Edit:
Wenn man eine Fritzbox im Einsatz hätte und die Ports der interaktiven Anwendung, die man im Internet nutzt, könnte man an der Priorisierung der Pakete arbeiten und das dort unter Internet->Filter->Priorisierung eintragen. Zuvor muss man bei Internet->Filter->Listen die Anwendung mit Ports usw. spezifizieren, dann kann man sie in der Priorisierung als Priorisierte oder sogar Echtzeit-Anwendung eintragen. Vorsicht, wenn man dort Anwendungen mit hohem Datendurchsatz priorisiert, macht man damit praktisch seine Internetanbindung platt, während die Datenübertragung läuft. Man darf also das streamen nicht priorisieren, wenn man dort lost frames hat, sondern man muss schon sein Spiel priorisieren. Vorsicht mit Echtzeit, wenn im Spiel-Datenstrom auch Download von Game-Assets mitschwimmen, dann darf man dem Spiel nicht zuviel Priorität geben.

Edit2:
Obiges mit Fritz!OS 7.01, der Provider-Firmware. Ich kann mich daran erinnern, dass zu Zeiten der Firmware 6.52 das Latenzverhalten viel schlimmer war und bei Uploads wie oben 100-150 ms Latenz anlagen. Leider kann ich euch davon keine Grafiken zeigen, das ist zu lange her.