Frage
Antwort
Lösung
Hallo,
Zunächst einmal meine Daten:
Vertrag: Red Internet & Phone 50 Cable U
Router: Fritzbox 6490 Cable (1) / Vodafone Box TG3442DE (2)
(1) ist mein Gerät. (2) das Leihgerät, das ich mit dem Vetrag erhalten habe
Fehler: Erhebliche Abweichung Downstream / Upstream / Latenzzeiten nur in den Abendstunden, täglich, seit > 2 Wochen.
Anbindung an Modem: Gigabit LAN
Betriebssystem: Linux, Browser: Chrome, Tests auch per wget
Wohnort: Hamburg
Zu den angegenen Zeiten ist eine Nutzung kaum möglich: TV Streaming bricht ab oder verpixelt, Onlinespiele frieren ein oder sind aufgrund der Latenz (Lag) nicht spielbar.
Ich bin zum Teil auf 3-4 MBit/s im Download runter und ~1MBit im Upstream. Ich habe auch schon Messungen von 0 im Upstream gehabt. Latenz ist zum Teil bei ~250ms und das gegen der ersten HOP (Vodafone Netz)
Ich habe eine protokollierte Messkampagne per Breitbandmessung am 23/24.04 mit der Originalhardware (2) angefertigt, mit deaktivem WLAN und alleinigem Client während des Tests.
Das habe ich im Kundencenter hochgeladen und anschliessend wurde ein Techniker Termin vereinbart, obwohl ich darauf hingewiesen habe, dass dee Leistungeinbruch nur zu bestimmten Zeiten aber regelmässig auftritt, zu anderen Zeiten ist die Leitung stabil und auch die Messwerte stimmen (daher gehe ich nicht von Fehlern im Setup / Messaufbau etc aus)
Der Techniker hat am 27. dennoch einige Einstellungen am Hausverstärker vorgenommen, und ein 10dB Dämfungsglied in die Modemantennenleitung eingeschleift.
Leider hat das nichts geändert, die Werte waren am 27. Abends wieder schlecht wie üblich (Test mit Hardware 2)
Ich habe am 28. morgens wieder meine FB angeschlossen, weil ein dadurch bedingter Fehler ausgeschlossen werden kann und ich auf mein DECT Telefon angewiesen bin.
Ich habe diverse browserbasierte Tests auf verschiedenen Endgeräten unterschiedlicher Anbieter verwendet:
breitbandmessung / unitymedia / netcologne / wieistmeineip
und um Browser als Fehler auszuschliessen auch Kontrollmessungen per wget
speedtest.tele2.net / speedtest.belwue.net /
Ein Router Neustart (1) oder (2) war ebenso erfolglos.
Der Test von UnityMedia darf hier übrigens ersthaft angezweifelt werden, es scheinen immer die Maxima von 5 Einzelmessungen angezeigt zu werden, Bsp test Tachos 38-27-11-15-19 und dann Anzeige 38. Der Download zum Modem ist ständig 58, egal welcher Router und eine zeitnahe Messung mit anderen Tools brachte ganz andere und deutlich schlechtere Werte. Allein das Laden des Startbildes dauerte 3-5 Sekunden, wo man zusehen konnte.....
Ich hab hier noch einiige Tests in Textform
28.04 21:41 http://speedtest.netcologne.de/ TestId 609369 Down: 3.81 MBit/s, Ping 209 ms, Up 0.24 MBit/s ### $ wget -O /dev/null --report-speed=bits -4 http://speedtest.belwue.net/random-100M --2021-04-28 21:28:19-- http://speedtest.belwue.net/random-100M Resolving speedtest.belwue.net... 129.143.4.238 Connecting to speedtest.belwue.net|129.143.4.238|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) Saving to: '/dev/null' /dev/null 3%[=> ] 3.87M 459Kb/s eta 26m 40s ^C ### --2021-04-28 21:36:33-- ftp://speedtest.tele2.net/100MB.zip => »100MB.zip« Auflösen des Hostnamens speedtest.tele2.net (speedtest.tele2.net) … 90.130.70.73, 2a00:800:1010::1 Verbindungsaufbau zu speedtest.tele2.net (speedtest.tele2.net)|90.130.70.73|:21 … verbunden. Anmelden als anonymous … Angemeldet! ==> SYST ... fertig. ==> PWD ... fertig. ==> TYPE I ... fertig. ==> CWD nicht notwendig. ==> SIZE 100MB.zip ... 104857600 ==> PASV ... fertig. ==> RETR 100MB.zip ... fertig. Länge: 104857600 (100M) (unmaßgeblich) 100MB.zip 5%[> ] 5,76M 185KB/s ETA 7m 1s ^C ### $ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) Bytes Daten. 64 Bytes von 8.8.8.8: icmp_seq=1 ttl=116 Zeit=2074 ms 64 Bytes von 8.8.8.8: icmp_seq=2 ttl=116 Zeit=6528 ms 64 Bytes von 8.8.8.8: icmp_seq=5 ttl=116 Zeit=3592 ms 64 Bytes von 8.8.8.8: icmp_seq=6 ttl=116 Zeit=2669 ms 64 Bytes von 8.8.8.8: icmp_seq=7 ttl=116 Zeit=3852 ms 64 Bytes von 8.8.8.8: icmp_seq=8 ttl=116 Zeit=3351 ms 64 Bytes von 8.8.8.8: icmp_seq=10 ttl=116 Zeit=1521 ms 64 Bytes von 8.8.8.8: icmp_seq=11 ttl=116 Zeit=1523 ms 64 Bytes von 8.8.8.8: icmp_seq=12 ttl=116 Zeit=618 ms 64 Bytes von 8.8.8.8: icmp_seq=13 ttl=116 Zeit=245 ms 64 Bytes von 8.8.8.8: icmp_seq=14 ttl=116 Zeit=179 ms
Techniker war da. Hat wohl Hausverstärker nochmal eingestellt, das Dämpfungsglied wieder entfernt und geflucht 🙂 Ich hab nun 4 Upload Kanäle, aber dennoch wieder Einbrüche gerade im Upload. Es soll wohl kein Störer mehr auf dem Segment sein sondern eine Überlast. Ich hatte den ganzen Tag heute schon, also noch vor derm Techniker extreme Schwankungen im Upload , das war vorher definitiv nur zu den gemeldeten Zeiten anders, siehe Bilder:
Hier nochmal 5 Tage zurück, seit ich angefangen habe zu messen. Die blaue Annotation zeigt den Technikerstart
Ja, ich weiss, heute ist Montag, am Sa + So ist die Linie kerzengerade. An den Wochentagen zuvor wird die Leitung auch benutzt, aber ich habe versucht auf die Messzeiten zu achten und zur vollen Stunde enden die meisten Konferenzen ohnehin....
Hallo Claudia,
über welchen Betrag bzw Prozentsatz reden wir hier?
Da VF als Monopolist auftritt, bin ich vornehmlich an einer Lösung interessiert als an Kompensation.
Ich bin nach wie vor der Meinung, dass es eine Rückwegsstörung gibt. Es gibt einige sehr gute technische Erklärungen im "Rückwegstörer" Thread, die mir komplett einleuchten. Die Modulation im Upstream wird runtergesetzt, weil das Signal so verfälscht ist, das es nicht mehr dekodierbar ist. Ein Lastproblem würde sich ganz anders äussern: Die CPEs fordern im TDM mehr Slots an als verfügbar sind, damit ist das Segment ausgelastet, aber die Modulation auf der Leitung bleibt auf den höherwertigen Standards. Es wäre komplett Nonsens, wenn in Spitzenlastzeiten nur noch mit geringertigen Modulationsarten gesendet wird, damit noch weniger Durchsatz erzielt wird. Auch das Dein Kollege behauptet, durch die gestiegene Anzahl von Modems würde der Upload verrauscht mag ja stimmen, erklärt aber nicht das die Leitung um 19 Uhr zusammenbricht und ab 0 Uhr wieder funktioniert. Schalten da alle gemeinschaftlich Ihr Modem an und aus?
Ich kann nach dem Modulationsabfall die Uhr stellen, selbst gestern am verregneten Feiertag würde ich erwarten, das dort eine andere Nutzung erfolgt als an Werktagen, aber bei mir war alles ok bis 20:00 Uhr die Uploadmodulation wieder auf 4x4QAM zusammenbrach. Das sorgt dann auch dafür das kein Downstream mehr möglich ist, inklusive SIP, wobei da die technischen Erfordernisse wegen UDP und QoS noch ein klein wenig anders sind. Das ganze dauerte dann wieder bis Mitternacht.
Was hat die Störungseingrenzung ergeben? Ich würde erwarten das das Enstörungsticket des Uploadstörers wieder geöffnet wird, weil das Problem nicht beseitigt ist.
Ich hab leider von gestern nur bedingt Daten, da ich am Monitoring gebastelt hab, aber das Verhalten ist / war wir jeden Tag. Ich bekomme übrigens nie 256QAM sondern maximal 4x64, und zwar rund um die Uhr, dies wäre vielleicht mit einem verrauschten Upload zu erklären.
14. Mai, tagsüber ok, Modulation im Upload bei 64QAM, ganz selten mal 1 Kanal auf 32QAM.
Ab 20:30 dann Beginn der Rückwegsstörung,: Upload Modulation beginnt zu wackeln, bis dann nur noch 4QAM verbleiben. Upload Bandbreite bricht ein, diesmal nciht so schlimm auf 400KBit/s. Abends messe ich die Bandbreite im 30 Minuten Raster:
