Frage
Antwort
Lösung
30.01.2020 23:10 - bearbeitet 30.01.2020 23:12
Hallo,
ich bin mit meiner 100 down /50 up Leitung seit ca. einem Monat von kurzen Aussetzern im Upload betroffen. Diese resultieren in Packet Loss bei Echtzeitübertragungen. Vor allem in Discord und beim Streamen auf Twitch ist das sehr ärgerlich, da ich dadurch nur mit einer sehr niedrigen Bitrate (~4500kbps) streamen kann und dennoch eine Rate von ca. 1-2% dropped Frames habe. Bevor das Problem aufgetreten ist, war es kein Problem ohne Aussetzer mit 6000 bis 8000kbps zu streamen.
Aktuell nutze ich eine selbst gekaufte Fritz!Box 6591. Die Fehler treten allerdings auch mit dem Vodafone TechniColor Modem auf.
Gibt es irgendwelche Tips, die ich befolgen könnte um das Problem zu lösen? Ich nutze keinerlei Powerline Geräte, die den Upload stören könnten.
Danke und freundliche Grüße
Timo
am 20.02.2020 21:54
Hallo Fred,
danke für das erneute Einstellen des Tickets.
Heute Mittag wurde das Ticket geschlossen. Der Packet Loss scheint jedoch noch vorhanden zu sein. Ein direktes Streamen auf Twitch ohne TCP BBR war mir heute abend ebenfalls unmöglich.
Gibt es noch irgendwas was ich von meiner Seite tun könnte, um das Problem zu lösen?
Danke und freundliche Grüße
Timo
am 22.02.2020 11:15
Hallo Timo911,
ich sehe auch keine Veränderung. Ich habe einen neuen Auftrag eingestellt.
Gruß Fred
am 24.02.2020 17:25
Hallo Fred,
danke für das erneute öffnen des Tickets. Heute wurde es schon wieder geschlossen. Der Packet Loss ist aber leider nach wie vor vorhanden.
Ich bin jetzt etwas überfragt, wie ich weiter vorgehen soll, wenn das Ticket ständig vom System wieder geschlossen wird. Gibt es sonst noch was, das ich tun könnte, damit das Problem eingegrenzt und gelöst werden kann?
Das sich die Behebung des Problems wohl noch hinziehen wird, besteht irgendwie die Möglichkeit die gestörte Uploadfrequenz vorrübergehend zu filtern bzw. im Modem zu blockieren?
Viele Grüße
Timo
am 26.02.2020 16:33
Hallo Timo911,
"Das sich die Behebung des Problems wohl noch hinziehen wird, besteht irgendwie die Möglichkeit die gestörte Uploadfrequenz vorübergehend zu filtern bzw. im Modem zu blockieren?"
Diese Möglichkeit besteht leider nicht. Wir können nur den technischen Bereich informieren, sodass diese den Störer eingrenzen und die Quelle für die Einstrahlung beseitigen. Die Kollegen machen auch immer was, nur leider sind die Maßnahmen nicht von Dauer 😞 Aktuell ist aber die Fehlerrate im Vergleich zum letzten Auftrag runter gegangen. Kannst Du bitte nochmal einen Test zum PL hinterlegen?
Gruß Fred
am 26.02.2020 18:21
Hallo Fred,
ich hab immernoch genau den gleichen Packet Loss zum ersten Hop. Ich kann aus meiner Sicht keinerlei Veränderung feststellen:
My traceroute [v0.92]
2020-02-26T18:10:37+0100
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. fritz.box 99.6% 270 0.6 0.6 0.6 0.6 0.0
2. ipXXXXXXXX.dynamic.kabel-deutsch 0.0% 270 9.1 20.2 6.6 440.8 35.3
3. ip5886dd1e.static.kabel-deutschl 0.0% 270 13.2 20.0 8.4 270.6 24.6
4. ip5886c2cd.static.kabel-deutschl 0.0% 269 14.6 19.9 10.6 262.6 20.4
5. ip5886edf8.static.kabel-deutschl 0.4% 269 16.6 26.1 15.7 263.1 24.9
6. ip5886ed3f.static.kabel-deutschl 0.7% 269 29.3 25.9 13.0 714.8 52.3
7. ae0-429.fra20.core-backbone.com 0.0% 269 20.5 29.2 16.2 499.9 46.6
8. core-backbone.belwue.de 0.0% 269 24.7 28.2 16.3 713.3 44.8
9. stu-nwz-a99-hu0-2-0-0.belwue.net 0.7% 269 19.5 27.9 17.1 486.8 33.6
10. XXX.XXX.XX.XX 0.0% 269 21.6 28.7 20.1 237.0 20.4
11. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0.0% 269 22.4 28.1 18.1 178.0 18.0 My traceroute [v0.87]
Wed Feb 26 17:17:56 2020
Resolver error: No error returned but no answers given. of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. XXX.XXX.XXX.X 0.0% 871 0.4 0.4 0.3 28.5 1.0
2. stu-nwz-a99-hu0-2-0-2.belwue.net 0.0% 871 3.6 3.5 3.3 9.7 0.4
3. fra-decix-1-hu0-0-0-4.belwue.net 0.0% 871 7.1 7.5 6.8 101.0 6.1
4. decix2.superkabel.de 0.0% 870 7.2 7.2 7.1 10.6 0.1
5. ip5886eda2.static.kabel-deutschl 0.0% 870 7.2 7.2 7.1 8.3 0.0
6. ip5886edff.static.kabel-deutschl 0.0% 870 8.7 8.7 8.6 15.1 0.2
7. ip5886c2c9.static.kabel-deutschl 0.0% 870 11.0 11.3 10.5 40.0 1.2
8. ip5886dd11.static.kabel-deutschl 0.0% 870 10.3 11.7 9.5 70.6 7.3
9. ipXXXXXXXX.dynamic.kabel-deutsch 0.6% 870 24.0 27.7 16.4 598.3 36.7ESTAB 0 794952 192.168.1.207:https XXX.XXX.XXX.XXX:46132 timer:(on,244ms,0) uid:33 ino:167071742 sk:85 <->
ts sack cubic wscale:7,7 rto:264 rtt:61.847/25.609 ato:40 mss:1448 pmtu:1500 rcvmss:536 advmss:1448 cwnd:17 ssthresh:17 bytes_acked:406626281 bytes_received:565 segs_out:282676 segs_in:129971 data_segs_out:282674 data_segs_in:3 send 3.2Mbps lastsnd:20 lastrcv:275852 lastack:20 pacing_rate 8.5Mbps delivery_rate 3.2Mbps busy:276084ms rwnd_limited:20ms(0.0%) unacked:39 retrans:3/1814 lost:3 sacked:22 reordering:136 rcv_space:28960 rcv_ssthresh:31104 notsent:738480 minrtt:14.438TCP Verbindungen fallen durch den Packet Loss immernoch auf ca. 3-4 mbit/s zurück.
Viele Grüße
Timo
am 28.02.2020 12:04
Hallo Timo911,
aber laut Deinem Test geht zum Ziel nichts verloren. Bedeutet, es gibt keine Probleme mit PL. Da stimmt doch was nicht. Vermutlich werden die Pakete von der Fritz!Box einfach gedroppt.
Gruß Fred
28.02.2020 13:20 - bearbeitet 28.02.2020 13:21
Hallo Fred,
laut dem Test gehen sehr wohl zwischen dem CMTS und meinem Router 0.6% der Pakete verloren (Zeile 9 im zweiten mtr vom Server zu mir). Wie man in der Ausgabe der Socket Stats einer TCP Übertragung zu meinem Server erkennt, führt das zu einer ganzen Menge an "unacked", "lost" und "retrans" Paketen und damit verbunden zu einer sehr niedrigen delivery rate von 3.2Mbps, wo eigentlich 50 Mbps messbar sein müssten. Die 99.6% verlorenen Pakete im traceroute zu meiner FritzBox sind der ICMP Firewall geschuldet, die haben aber auch nichts mit dem Problem zu tun.
Das Problem tritt aber auch ohne FritzBox, auf mehreren PCs und direkt per LAN Kabel an eurem Modem auf. Das hatten wir ja schon auf Seite 1 festgestellt.
Die Zahlen deuten für mich immernoch auf eine gestörte Übertragung zwischen Modem und CMTS hin. Wo der Fehler genau liegt, kann ich nicht sagen. Aber es ist auf jedenfall noch irgendwo eine Störquelle aktiv. Sonst würden nicht konstant rund um die Uhr 0.5% - 1% der Pakete verloren gehen.
Ich kann jetzt auf meinem Linux Rechner den TCP Stack auf BBR congestion control umstellen und damit den Packet Loss ignorieren. Dann ist die Bandbreite im Upload wieder bei 48 Mbps. Das funktioniert aber nicht auf meinen Windows Geräten, dem Smartphone und dem Tablet.
Das Problem ist halt das komplette Einbrechen des Uploads durch den kontinuierlichen Paketverlust. Der TCP Stack geht solange mit der Bandbreite runter, bis es keine Anzeichen mehr für "congestion" gibt. Der Paket Loss bleibt aber durch die Störquelle dauerhaft, egal bei welcher Bandbreite, weswegen die Datenrate komplett in den Keller geht. Die Fehlerrate scheint inzwischen etwas geringer zu sein. Solange sie jedoch nicht ganz weg ist, wird sich an meiner niedrigen Uploadbandbreite nichts ändern.
Ich würde daher noch einmal bitten, dass sich die Technik meine Leitung ansieht.
Viele Grüße
Timo
28.02.2020 17:30 - bearbeitet 28.02.2020 17:49
Hier noch zur Ergänzung ein aktueller Speedtest:
Denke hier wird das Problem am deutlichsten, ohne groß traceroutes und socket stats zu analysieren.
Viele Grüße und ein schönes Wochenende
Timo
am 02.03.2020 09:04
Hallo Timo911,
ich habe einen neuen Auftrag für den Folgebereich eingestellt. Die Kollegen prüfen den Rückweg erneut auf Fehler. Du bekommst die Rückinfo via SMS.
Gruß Fred
am 04.03.2020 01:41
Hallo Fred,
das Ticket wurde erneut geschlossen, ohne dass sich am Packet Loss etwas verändert hat. Inzwischen habe ich herausgefunden, dass man sich die gesendeten und verlorenen Pakete in der Windows Leistungsanzeige darstellen lassen kann:
Die grüne Linie sind die übertragenen Pakete während eines Livestreams auf Twitch. Die Rote Linie sind Pakete die durch Packet Loss erneut übertragen werden mussten. Jedes mal, wenn Pakete verloren gehen, bricht die Übertragungsrate ein.
Der Paket Loss scheint jetzt etwas seltener aufzutreten, aber der Störer ist immernoch aktiv.
Ich bin inzwischen total ratlos, wie ich mit dem Problem weiter umgehen soll. Wäre es möglich meinen Anschluss auf VDSL zu wechseln? Aktuell scheint ja keine Lösung des Problems am Kabelanschluss absehbar.
Viele Grüße
Timo