Unitymedia Bufferbloat eliminieren für Streaming auf Twitch

[Andreas1969]

Jittert schon, nur viel weniger als DOCSIS.

So meinte ich das auch :zwinker:
Eben nicht merklich.

 

[F-orced-customer]

Und das ICMP-Protokoll ist dann kein Stream, weil ? Du widersprichst dir.
https://stackoverflow.com/questions/17446491/tcp-stream-vs-udp-message

Jaaha theoretisch stimmt das aber welcher use case? ntp broadcasts? rtp ist doch eher stream statt message.

 

[boba]

Ich würde ja wirklich erstmal in der Fritzbox die erweiterte Ansicht einschalten, dann in o.a. Listen-Definitionen die Ports eintragen, die mein Lieblingsshooter verwendet, und das dann als Echtzeit-Anwendung in der Priorisierung eintragen. Für CSGO Ports siehe z.B. hier: https://steamcommunity.com/app/730/discussions/0/35222218619577126/?l=german
Da würde ich alle udp Ports und von den tcp Ports alle bis auf die "steam downloads" priorisieren.
Die Definition für udp Port 27000-27015 müsste z.B. so aussehen:

 

[Andreas1969]

Ich würde ja wirklich erstmal in der Fritzbox die erweiterte Ansicht einschalten, dann in o.a. Listen-Definitionen die Ports eintragen, die mein Lieblingsshooter verwendet, und das dann als Echtzeit-Anwendung in der Priorisierung eintragen.

Und was machen die Connectboxler :kratz:

 

[F-orced-customer]

Ich würde ja wirklich erstmal in der Fritzbox die erweiterte Ansicht einschalten, dann in o.a. Listen-Definitionen die Ports eintragen, die mein Lieblingsshooter verwendet, und das dann als Echtzeit-Anwendung in der Priorisierung eintragen.

Und was machen die Connectboxler :kratz:

Die tragen den TOS eben aufm client ein, bei Asterisk geht das z.B.

 

[Wechseler]

Nein, die RTT ist nicht jitter aber bitte:

Schwankende RTT ist Jitter. Nur darum geht's hier. Das Problem zu verstehen ist schon die Hälfte der Miete. :smile: Kein QoS im Endkundenrouter ändert daran etwas, weil er durch die Belegung des DOCSIS-Upstreams bedingt ist. Wenn gerade ein anderes Modem im betreffenden Kanal sendet, kann das eigene Datagram nicht auf Reise, egal wie dringend es ist. Selbst mit DOCSIS-seitigem QoS ist das nicht lösbar, weil auch eine bevorzugte Zuteilung von Zeitschlitzen nicht eine Zuteilung aller Zeitschlitze bewirkt. Die anderen Kunden im Segment müssen komplett raus, anders geht es nicht.

--- www.google.de ping statistics ---
244 packets transmitted, 244 received, 0% packet loss, time 24463ms
rtt min/avg/max/mdev = 8.463/14.668/39.232/3.995 ms

Und zeigt es wunderschön an: 4 ms Standardabweichung, 32 ms (-6/+26) Schwankungsbreite. Mit 32 ms kommt eine Hit Prediction auf keinen grünen Zweig mehr. Deswegen trifft unser Gamer-Kollege nichts. :zwinker: Fast genauso übel wie Mobilfunk.

Bei VoIP behilft man sich da notdürftig mit einem riesigen Jitter-Buffer (z. B. 300 ms), sprich: man verzögert die Sprachausgabe einfach nochmal um mehr als eine Viertelsekunde und sortiert die unterschiedlich schnellen Sprachpakete wieder in die richtige (zeitliche) Reihenfolge. Im Use Case unseres Threaderstellers geht das nicht. Da müßte man nämlich alle Beteiligten entsprechend verzögern ("Lag") und das macht kein Gaming-Anbieter, weil die Kundschaft dann nämlich sofort schreiend die Flucht ergreift.

Das wird übrigens noch sehr lustig, wenn Google mit Stadia um die Ecke kommt und unsere KNB feststellen, daß sie eine Anschlußtechnologie haben, die dafür schlicht nicht vernünftig geeignet ist.

 

[Andreas1969]

Das wird übrigens noch sehr lustig, wenn Google mit Stadia um die Ecke kommt und unsere KNB feststellen, daß sie eine Anschlußtechnologie haben, die dafür schlicht nicht vernünftig geeignet ist.

Da bin ich aber mal gespannt

 

[rv112]

Man kann das halt alles nicht verallgemeinern. Hier meine DOCSIS Leitung:


Und hier die DSL Leitung:

 

[Andreas1969]

Man kann das halt alles nicht verallgemeinern. Hier meine DOCSIS Leitung:

78AE39E8-4DDD-432B-AD14-7DAABB6D0080.jpeg

Und hier die DSL Leitung:

F5A0E6F4-2FBC-4756-8CD4-035836306188.jpeg

Du wohnst ja auch neben der Vermittlungsstelle, bzw. auf dem Fiber Node

 

[Andreas1969]

Interessant wäre es mal zu sehen, wie es bei @Robert in Berlin in einem vollen Segment größer 1000 Kunden und Docsis 3.1 Gigabit Anschluss aussieht :kratz:

 

[rv112]

Viele wohnen um Fibrenodes, doch die meisten nutzen Schrotthardware oder haben sie nicht sauber konfiguriert. Mein Segment ist übrigens mit 800 Kunden belegt.

 

[F-orced-customer]

--- www.google.de ping statistics ---
244 packets transmitted, 244 received, 0% packet loss, time 24463ms
rtt min/avg/max/mdev = 8.463/14.668/39.232/3.995 ms

Und zeigt es wunderschön an: 4 ms Standardabweichung, 32 ms (-6/+26) Schwankungsbreite.

Und wie kommt iperf3 dann zu dem jitter ergebnis?

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.000 ms 0/4440 (0%) sender
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.075 ms 1/4440 (0.023%) receiver

Laut source comments ist die berechnung gem. RFCs :kratz:

 

[wittmann]

[...]Bei VoIP behilft man sich da notdürftig mit einem riesigen Jitter-Buffer (z. B. 300 ms), sprich: man verzögert die Sprachausgabe einfach nochmal um mehr als eine Viertelsekunde und sortiert die unterschiedlich schnellen Sprachpakete wieder in die richtige (zeitliche) Reihenfolge.[...]

Und genau fuer VoIP ueber Kabel wurde dQoS mit Service Flows eingefuehrt, welche ein UGS Scheduling verwenden. Hat irgendein Marketing-Typ mal faelschlicherweise als Voice over Cable verkauft, war in Wahrheit aber halt ganz normales VoIP im Kabelnetz mit dQoS. Mit UGS wird der Jitter im Upstream unter 1 ms gedrueckt. Im Downstream betraegt der Jitter ebenfalls unter 1ms zwischen CMTS und CM. Wenn man natuerlich VoIP dilettantisch ueber Best Effort abwickelt, muss man halt mit Jitter leben, wobei ein Jitter-Buffer fuer Voice mit 300ms doch arg realitaetsfern ist. Aber partout behaupten mit DOCSIS währe kein geringer Jitter moeglich ist absolut falsch! So kommt Deine Aussage zumindest rueber.

 

[robert_s]

Und genau fuer VoIP ueber Kabel wurde dQoS mit Service Flows eingefuehrt, welche ein UGS Scheduling verwenden. Hat irgendein Marketing-Typ mal faelschlicherweise als Voice over Cable verkauft, war in Wahrheit aber halt ganz normales VoIP im Kabelnetz mit dQoS. Mit UGS wird der Jitter im Upstream unter 1 ms gedrueckt. Im Downstream betraegt der Jitter ebenfalls unter 1ms zwischen CMTS und CM. Wenn man natuerlich VoIP dilettantisch ueber Best Effort abwickelt, muss man halt mit Jitter leben, wobei ein Jitter-Buffer fuer Voice mit 300ms doch arg realitaetsfern ist. Aber partout behaupten mit DOCSIS währe kein geringer Jitter moeglich ist absolut falsch! So kommt Deine Aussage zumindest rueber.

Und mit "Low Latency DOCSIS" soll die Latenz/Jitter-Reduzierung "verallgemeinert" werden, um grundsätzlich RTTs von 1ms auf der DOCSIS-Strecke für zeitkritische Anwendungen zu erreichen. Mit reinen Softwareupdates für CMTS und Kabelmodems.

Warum hat man das nicht schon längst gemacht? Weil bisher meistens die Datenrate der begrenzende Faktor war und Latenz/Jitter einen vernachlässigbaren Einfluss hatte. Inzwischen sind die Datenraten aber so hoch, dass z.B. der Seitenaufbau komplexer Webseiten mehr von der Latenz als vom Datendurchsatz abhängt.

Zudem wird ja speziell 5G mit der niedrigen Latenz beworben, d.h. Latenz ist zu einem "Verkaufsargument" geworden. Entsprechend kann sich DOCSIS dem auch nicht mehr entziehen. Zumal es sich ja als "10G" weiterentwickeln will...

 

[robert_s]

Kein QoS im Endkundenrouter ändert daran etwas, weil er durch die Belegung des DOCSIS-Upstreams bedingt ist. Wenn gerade ein anderes Modem im betreffenden Kanal sendet, kann das eigene Datagram nicht auf Reise, egal wie dringend es ist.

Du hast aber wieder unterschlagen, dass VDSL2 eine Symbolrate von lediglich 4kbaud verwendet, während es bei DOCSIS 3.0 Upstreams 5,12Mbaud sind. D.h. während Dein DSL-Modem auf das nächste Symbol wartet, weil das "dringende" Paket gerade das letzte verpasst hat, können im DOCSIS-Segment über 1000 Kabelmodems etwas senden...

Im worst case muss das Paket im VDSL2-Modem sogar 0,5ms warten, wenn nämlich gerade ein Synchronisationssymbol einzufügen ist (alle 256 Symbole).

 

[sch4kal]

--- www.google.de ping statistics ---
244 packets transmitted, 244 received, 0% packet loss, time 24463ms
rtt min/avg/max/mdev = 8.463/14.668/39.232/3.995 ms

Und zeigt es wunderschön an: 4 ms Standardabweichung, 32 ms (-6/+26) Schwankungsbreite.

Und wie kommt iperf3 dann zu dem jitter ergebnis?

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.000 ms 0/4440 (0%) sender
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.075 ms 1/4440 (0.023%) receiver

Laut source comments ist die berechnung gem. RFCs :kratz:

Gefunden, laut RFC3550.
Berechnet mtr aber analog mit dem „Interarrival Jitter“, der bei mir entsprechend hoch geht.
Eine Erklärung oder Paper dazu warum das besser sein soll als die Berechnung des Jitters von anderen Utilities wie Ping von Windows bist du aber immernoch schuldig.

@rv112: du hast aber auch ein Arris CMTS, bei meinem Casa CMTS sieht das nicht so schön aus.

 

[rv112]

Klar, das Arris CMTS ist natürlich besser. Daher sagte ich ja, man kann nicht verallgemeinern.

 

[Wechseler]

Im worst case muss das Paket im VDSL2-Modem sogar 0,5ms warten, wenn nämlich gerade ein Synchronisationssymbol einzufügen ist (alle 256 Symbole).

Und an 500 µs ist jetzt was dramatisch? Da habe ich schon größere Latenzen bei Ethernet-Switching gesehen.

Es gibt unbestreitbar ein Problem und Low-Latency-DOCSIS soll dafür Abhilfe schaffen. Spannend dürfte da vor allem die Frage sein, wann das nach Neuland kommt. :winken:

 

[F-orced-customer]

--- www.google.de ping statistics ---
244 packets transmitted, 244 received, 0% packet loss, time 24463ms
rtt min/avg/max/mdev = 8.463/14.668/39.232/3.995 ms

Und zeigt es wunderschön an: 4 ms Standardabweichung, 32 ms (-6/+26) Schwankungsbreite.

Und wie kommt iperf3 dann zu dem jitter ergebnis?

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.000 ms 0/4440 (0%) sender
[ 5] 0.00-10.00 sec 5.96 MBytes 5.00 Mbits/sec 0.075 ms 1/4440 (0.023%) receiver

Laut source comments ist die berechnung gem. RFCs :kratz:

Gefunden, laut RFC3550.
Berechnet mtr aber analog mit dem „Interarrival Jitter“, der bei mir entsprechend hoch geht.
Eine Erklärung oder Paper dazu warum das besser sein soll als die Berechnung des Jitters von anderen Utilities wie Ping von Windows bist du aber immernoch schuldig.

Der neue timercode in iperf3 3.6+ git scheint murks zu sein:

$ iperf3 -c ping.online.net -p 5209 -u -R -b500k
Connecting to host ping.online.net, port 5209
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.0.105 port 48897 connected to 62.210.18.40 port 5209
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 61.9 KBytes 507 Kbits/sec 5660089156.445 ms 0/45 (0%)
[ 5] 1.00-2.00 sec 60.5 KBytes 496 Kbits/sec 330795378.858 ms 0/44 (0%)
[ 5] 2.00-3.00 sec 61.9 KBytes 507 Kbits/sec 18124535.039 ms 0/45 (0%)
[ 5] 3.00-4.00 sec 60.5 KBytes 496 Kbits/sec 1059261.285 ms 0/44 (0%)
[ 5] 4.00-5.00 sec 60.5 KBytes 496 Kbits/sec 61907.048 ms 0/44 (0%)
[ 5] 5.00-6.00 sec 61.9 KBytes 507 Kbits/sec 3392.046 ms 0/45 (0%)
[ 5] 6.00-7.00 sec 60.5 KBytes 496 Kbits/sec 198.346 ms 0/44 (0%)
[ 5] 7.00-8.00 sec 61.9 KBytes 507 Kbits/sec 10.995 ms 0/45 (0%)
[ 5] 8.00-9.00 sec 60.5 KBytes 496 Kbits/sec 0.772 ms 0/44 (0%)
[ 5] 9.00-10.00 sec 60.5 KBytes 496 Kbits/sec 0.186 ms 0/44 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 610 KBytes 500 Kbits/sec 0.000 ms 0/444 (0%) sender
[ 5] 0.00-10.00 sec 610 KBytes 500 Kbits/sec 0.186 ms 0/444 (0%) receiver
iperf Done.

OK, bleiben wir bei ping zur jitter messung, hier ii iputils-ping 3:20121221-5+b2

 

[MKmasta]

Ich würde ja wirklich erstmal in der Fritzbox die erweiterte Ansicht einschalten, dann in o.a. Listen-Definitionen die Ports eintragen, die mein Lieblingsshooter verwendet, und das dann als Echtzeit-Anwendung in der Priorisierung eintragen. Für CSGO Ports siehe z.B. hier: https://steamcommunity.com/app/730/discussions/0/35222218619577126/?l=german
Da würde ich alle udp Ports und von den tcp Ports alle bis auf die "steam downloads" priorisieren.
Die Definition für udp Port 27000-27015 müsste z.B. so aussehen:
bb2.png

Muss es TCP oder UDP sein?!
Wieso ist der Quellport egal und woher weiss ich was der Unterschied zwischen dem Quell und Zielport ist?

 

[MKmasta]

Nein, die RTT ist nicht jitter aber bitte:

Schwankende RTT ist Jitter. Nur darum geht's hier. Das Problem zu verstehen ist schon die Hälfte der Miete. :smile: Kein QoS im Endkundenrouter ändert daran etwas, weil er durch die Belegung des DOCSIS-Upstreams bedingt ist. Wenn gerade ein anderes Modem im betreffenden Kanal sendet, kann das eigene Datagram nicht auf Reise, egal wie dringend es ist. Selbst mit DOCSIS-seitigem QoS ist das nicht lösbar, weil auch eine bevorzugte Zuteilung von Zeitschlitzen nicht eine Zuteilung aller Zeitschlitze bewirkt. Die anderen Kunden im Segment müssen komplett raus, anders geht es nicht.

--- www.google.de ping statistics ---
244 packets transmitted, 244 received, 0% packet loss, time 24463ms
rtt min/avg/max/mdev = 8.463/14.668/39.232/3.995 ms

Und zeigt es wunderschön an: 4 ms Standardabweichung, 32 ms (-6/+26) Schwankungsbreite. Mit 32 ms kommt eine Hit Prediction auf keinen grünen Zweig mehr. Deswegen trifft unser Gamer-Kollege nichts. :zwinker: Fast genauso übel wie Mobilfunk.

Bei VoIP behilft man sich da notdürftig mit einem riesigen Jitter-Buffer (z. B. 300 ms), sprich: man verzögert die Sprachausgabe einfach nochmal um mehr als eine Viertelsekunde und sortiert die unterschiedlich schnellen Sprachpakete wieder in die richtige (zeitliche) Reihenfolge. Im Use Case unseres Threaderstellers geht das nicht. Da müßte man nämlich alle Beteiligten entsprechend verzögern ("Lag") und das macht kein Gaming-Anbieter, weil die Kundschaft dann nämlich sofort schreiend die Flucht ergreift.

Das wird übrigens noch sehr lustig, wenn Google mit Stadia um die Ecke kommt und unsere KNB feststellen, daß sie eine Anschlußtechnologie haben, die dafür schlicht nicht vernünftig geeignet ist.

Es ist ja nicht so dass ich gar nix mehr treffe. Ich habe nach wie vor noch immer sehr gute Spiele was aber auch an mir selbst liegt, dh. ich kann das etwas kompensieren.
Es gibt aber Situationen wo ich einfach nur sinnlos sterbe deswegen. Eben gerade je höher das Niveau wird, desto schwieriger wird das bei gleichzeitigem Stream, weil sich die Schwankungen erhöhen.

 

[MKmasta]

Man kann das halt alles nicht verallgemeinern. Hier meine DOCSIS Leitung:

78AE39E8-4DDD-432B-AD14-7DAABB6D0080.jpeg

Und hier die DSL Leitung:

F5A0E6F4-2FBC-4756-8CD4-035836306188.jpeg

Idle ist aber etwas völlig anderes als unter Last. Man sieht das sofort in jedem Tool.

 

[boba]

Ich würde ja wirklich erstmal in der Fritzbox die erweiterte Ansicht einschalten, dann in o.a. Listen-Definitionen die Ports eintragen, die mein Lieblingsshooter verwendet, und das dann als Echtzeit-Anwendung in der Priorisierung eintragen. Für CSGO Ports siehe z.B. hier: https://steamcommunity.com/app/730/discussions/0/35222218619577126/?l=german
Da würde ich alle udp Ports und von den tcp Ports alle bis auf die "steam downloads" priorisieren.
Die Definition für udp Port 27000-27015 müsste z.B. so aussehen:
bb2.png

Muss es TCP oder UDP sein?!
Wieso ist der Quellport egal und woher weiss ich was der Unterschied zwischen dem Quell und Zielport ist?

Ob eine Portdefinition für udp oder tcp ist, geht für o.a. Spiel aus o.a. verlinktem Post hervor. Bei anderen Spielen aus der entsprechenden Portbeschreibung für deren Ports. Bei diesen Portangaben geht es immer um Verbindungen, die von deinem PC ausgehen auf Zielports auf dem Gameserver. Es verbindet sich immer dein PC mit dem Gameserver, niemals der Gameserver auf deinen PC. Also sind es ausgehende Verbindungen, und die Zielports sind die, die man in o. a. Beschreibung findet. Die Quellports sind bei solchen Verbindungen immer variabel. Feste Quellports bei ausgehenden Verbindungen hast du praktisch nie - das ist unüblich.