Bis zu 80% packet loss zu Azure - Hotline schickt ...

ChristianSo · ‎14.02.2022

In welchem Bundesland wohnst Du? Niedersachsen, 30175
Welchen Vertrag hast Du? Red Internet & Phone 1000 Cable
Welches Modem/ Router nutzt Du? (z.B. Hitron)
Nutzt Du ein Leih-Gerät von uns oder hast Du ein eigenes Gerät? Leih-Gerät
Welcher Fehler tritt auf? Packetloss (siehe Bilder unten) zu Diensten auf Microsoft Azure. Dadurch bedingt Downloadrate von 5 Mbps oder auch 0.5% maximaler Rate meines Vertrages.
Wie ist Dein Endgerät mit dem Modem verbunden? LAN
Welchen Browser verwendest Du normalerweise? Alle Browser und andere Anwendungen
Welches Betriebssystem hast Du auf Deinem Rechner? Windows
Beginn und Zeitraum der Störung: Seit dem 9.02.22 durchgängig: Morgens, nachts, abends, am Wochenende.
Lade dazu noch einen Screenshot von den Signalwerten hoch. Diese findest Du in der Benutzeroberfläche Deines Kabelrouters über 192.168.0.1 bzw. über 192.168.178.1 bei der Fritzbox.
Welche Maßnahmen wurden durch die Störungshotline durchgeführt? Neues Coaxialkabel ist auf dem Weg zu mir. Was auch immer das bringen soll. Außerdem wurde mein Vertrag um eine öffentliche IPv4 Adresse erweitert. Versteht sich von selbst. Nach dem fünften Anruf und über 4 Stunden verbrannter Zeit kommt morgen früh ein Techniker vorbei. Bin gespannt, wie der von hier aus die Probleme im Vodafone Netzwerk behebt.

Pingplotter zeigt Paketverlust im Vodafone / Microsoft Netzwerk bei über 800 pingsSpeedtest.net zu Vodafone in FrankfurtDOCSIS Status

Kieferer · ‎14.02.2022

Pegel sind ok

Speed ist ok

Pingplotter ein loss am Ziel? Das ist nicht erkennbar.

Falls ein Hop im Pingplotter Packete verwirft, so liegt das an der Netzgerätekonfiguration am Hop x, beispielsweise am ratelimit oder Pings werden generell verworfen.

Führe mehrfach einen Speedtest als singleuser bei speedtest.net durch. Damit wird nur ein Port für den Speedtest benutzt. Als singleuser bist du Daheim auch mit M$ Azure verbunden.

Der Download ist dabei irrelevant, nur der Upload ist von Interesse und sollte um die 50MBits liegen.Ich

Bist du mit VPN am Azure Netzwerk angebunden?

Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team

ChristianSo · ‎15.02.2022

Techniker war da und hat wenig überraschend keine Störung an meinen Geräten feststellen können. Das vorhandene Coaxialkabel ist auch super. Es gibt eine sproadische Rückwegstörung, aber die hat nur Einfluss auf den Upstream, nicht den Downstream. Der Techniker hat mir nochmal bestätigt, dass es sich um ein Routingproblem handelt und mit meinem Anschluss alles in Ordnung ist.

Ich habe Probleme mit dem Downstream spezifisch von Diensten in der Azure Cloud. Bei der Suche nach der Ursache sind in den Netzwerkdaten der Cloud Nodes haufenweise reconnects von meiner Verbindung aufgefallen. Andere User haben keine eingeschränkte Downloadrate feststellen können. Die Nodes laufen und liefern.

Der Ping trace zeigt, dass auf der Route Probleme liegen und das deckt sich mit dem Verhalten, was man auf den Cloud Nodes beobachten kann.

Das habe ich alles den verschiedenen Menschen der Störungshilfe ausführlich erklärt. Da brauche ich nicht nochmal anrufen. Obwohl sie wollen, können die mir nicht helfen, weil ihr System nicht mal die Eingabe meines Problems in ein Ticket ermöglicht.

Kein VPN.

Was genau soll ich jetzt tun?

ChristianSo · ‎15.02.2022

Repräsentativer single connection speedtest

Der Zielserver aus dem Pingplot antwortet nicht auf ping anfragen und hat deswegen 100% PL. Daher habe ich ihn auch nicht in die Grafik aufgenommen.

Kieferer · ‎15.02.2022

Dieser singleuser Test für 12sek. sieht im up gut aus.

Ein Ping ist ≠ TCP

Dein Pingplotter zeigt am Ziel keine PL's, was dazwischen abläuft ist unerheblich. Dazu kommt erschwerend das Azure auf meines Wissens mit ipv4 arbeitet. Ist dein Dual Stack aktiv?

Willst du das wirklich testen, brauchst du eine Langzeitauswertung mit iperf3 siehe auch Public Server und deren Ports.

Es kann durchaus sein das dein Speed nach einiger Zeit einbricht. Ein Speedtest bildet nur einen Zeitraum von ca. 15sek. ab.

Beispiel mit iperf3, nach excel importiert.

iperf für 20sek.

iperf3 -c iperf.par2.as49434.net -p9210 -t20 -V
iperf 3.7
Linux ThinkPad-P14s 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64
Control connection MSS 1448
Time: Tue, 15 Feb 2022 11:01:53 GMT
Connecting to host iperf.par2.as49434.net, port 9210
      Cookie: iozuzrmuufincufhcunzhx5oxsxakooxqnzu
      TCP MSS: 1448 (default)
[  5] local 10.16.252.1 port 36488 connected to 193.177.162.41 port 9210
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  7.21 MBytes  60.5 Mbits/sec    0    472 KBytes       
[  5]   1.00-2.00   sec  6.83 MBytes  57.3 Mbits/sec   10    451 KBytes       
[  5]   2.00-3.00   sec  5.94 MBytes  49.8 Mbits/sec    0    509 KBytes       
[  5]   3.00-4.00   sec  7.18 MBytes  60.3 Mbits/sec    1    390 KBytes       
[  5]   4.00-5.00   sec  5.94 MBytes  49.8 Mbits/sec    0    416 KBytes       
[  5]   5.00-6.00   sec  7.13 MBytes  59.8 Mbits/sec    0    430 KBytes       
[  5]   6.00-7.00   sec  5.94 MBytes  49.8 Mbits/sec    0    437 KBytes       
[  5]   7.00-8.00   sec  5.94 MBytes  49.8 Mbits/sec    0    437 KBytes       
[  5]   8.00-9.00   sec  7.13 MBytes  59.8 Mbits/sec    0    437 KBytes       
[  5]   9.00-10.00  sec  5.94 MBytes  49.8 Mbits/sec    0    438 KBytes       
[  5]  10.00-11.00  sec  7.13 MBytes  59.8 Mbits/sec    0    450 KBytes       
[  5]  11.00-12.00  sec  5.94 MBytes  49.8 Mbits/sec    0    464 KBytes       
[  5]  12.00-13.00  sec  7.13 MBytes  59.8 Mbits/sec    0    492 KBytes       
[  5]  13.00-14.00  sec  6.00 MBytes  50.3 Mbits/sec    1    379 KBytes       
[  5]  14.00-15.00  sec  6.00 MBytes  50.3 Mbits/sec   34    303 KBytes       
[  5]  15.00-16.00  sec  7.12 MBytes  59.8 Mbits/sec    0    335 KBytes       
[  5]  16.00-17.00  sec  5.94 MBytes  49.8 Mbits/sec    0    355 KBytes       
[  5]  17.00-18.00  sec  7.13 MBytes  59.8 Mbits/sec    0    365 KBytes       
[  5]  18.00-19.00  sec  5.94 MBytes  49.8 Mbits/sec    0    368 KBytes       
[  5]  19.00-20.00  sec  5.94 MBytes  49.8 Mbits/sec    0    372 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-20.00  sec   129 MBytes  54.3 Mbits/sec   46             sender
[  5]   0.00-20.04  sec   127 MBytes  53.1 Mbits/sec                  receiver
CPU Utilization: local/sender 0.5% (0.1%u/0.4%s), remote/receiver 5.8% (0.9%u/4.9%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

iperf3 -c iperf.par2.as49434.net -p9210 -t20 -V iperf 3.7 Linux ThinkPad-P14s 5.13.0-28-generic #31~20.04.1-Ubuntu SMP Wed Jan 19 14:08:10 UTC 2022 x86_64 Control connection MSS 1448 Time: Tue, 15 Feb 2022 11:01:53 GMT Connecting to host iperf.par2.as49434.net, port 9210 Cookie: iozuzrmuufincufhcunzhx5oxsxakooxqnzu TCP MSS: 1448 (default) [ 5] local 10.16.252.1 port 36488 connected to 193.177.162.41 port 9210 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 7.21 MBytes 60.5 Mbits/sec 0 472 KBytes [ 5] 1.00-2.00 sec 6.83 MBytes 57.3 Mbits/sec 10 451 KBytes [ 5] 2.00-3.00 sec 5.94 MBytes 49.8 Mbits/sec 0 509 KBytes [ 5] 3.00-4.00 sec 7.18 MBytes 60.3 Mbits/sec 1 390 KBytes [ 5] 4.00-5.00 sec 5.94 MBytes 49.8 Mbits/sec 0 416 KBytes [ 5] 5.00-6.00 sec 7.13 MBytes 59.8 Mbits/sec 0 430 KBytes [ 5] 6.00-7.00 sec 5.94 MBytes 49.8 Mbits/sec 0 437 KBytes [ 5] 7.00-8.00 sec 5.94 MBytes 49.8 Mbits/sec 0 437 KBytes [ 5] 8.00-9.00 sec 7.13 MBytes 59.8 Mbits/sec 0 437 KBytes [ 5] 9.00-10.00 sec 5.94 MBytes 49.8 Mbits/sec 0 438 KBytes [ 5] 10.00-11.00 sec 7.13 MBytes 59.8 Mbits/sec 0 450 KBytes [ 5] 11.00-12.00 sec 5.94 MBytes 49.8 Mbits/sec 0 464 KBytes [ 5] 12.00-13.00 sec 7.13 MBytes 59.8 Mbits/sec 0 492 KBytes [ 5] 13.00-14.00 sec 6.00 MBytes 50.3 Mbits/sec 1 379 KBytes [ 5] 14.00-15.00 sec 6.00 MBytes 50.3 Mbits/sec 34 303 KBytes [ 5] 15.00-16.00 sec 7.12 MBytes 59.8 Mbits/sec 0 335 KBytes [ 5] 16.00-17.00 sec 5.94 MBytes 49.8 Mbits/sec 0 355 KBytes [ 5] 17.00-18.00 sec 7.13 MBytes 59.8 Mbits/sec 0 365 KBytes [ 5] 18.00-19.00 sec 5.94 MBytes 49.8 Mbits/sec 0 368 KBytes [ 5] 19.00-20.00 sec 5.94 MBytes 49.8 Mbits/sec 0 372 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - Test Complete. Summary Results: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-20.00 sec 129 MBytes 54.3 Mbits/sec 46 sender [ 5] 0.00-20.04 sec 127 MBytes 53.1 Mbits/sec receiver CPU Utilization: local/sender 0.5% (0.1%u/0.4%s), remote/receiver 5.8% (0.9%u/4.9%s) snd_tcp_congestion cubic rcv_tcp_congestion cubic iperf Done.

Führe einen iper3 Langzeittest durch. Auch dein etwas verminderter Upload ist ein Indiz.

Kannst du Azure unter ipv6 anpingen?

Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team

Kieferer · ‎15.02.2022

Sorry, hatte ich überlesen

"Der Zielserver aus dem Pingplot antwortet nicht auf ping anfragen und hat deswegen 100% PL. Daher habe ich ihn auch nicht in die Grafik aufgenommen."

Da ist der Fall eingetreten das M$ das ICMP Protokoll abgedreht hat.

Könntest du nochmals die Upstreampegel posten, im ersten Post sind die Werte kaum erkennbar.

Der OFDMA Kanal sollte ein delta von ca. 6dB zu den QAM Kanälen aufweisen. Ich kann es nicht lesen, aber das sieht wesentlich geringer aus.

Als bei mir der OFDMA eingeführt wurde, war es mit einem beständigen Upload Speed vorbei.

Nach dem abdrehen des OFDMA ist wieder alles OK.

Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team

ChristianSo · ‎16.02.2022

DOCSIS Status - Nur Upstream

Downstream ist von Sekunde 0 schlecht (konstant 5 Mbps). Keine Veränderung auch nach Stunden.

Und klar ist TCP ≠ Ping aber auf der Suche nach Fehlern sind die Traces ein Indiz dafür, dass was nicht in Ordnung ist. Viel mehr kann ich von zu Hause auch einfach nicht prüfen wenn es um die Route geht.

An dieser Stelle schonmal Danke für den Input. Ich will auch nicht undankbar wirken.

Es ist echt frustrierend, dass Vodafone meine Argumente so komplett ignoriert hat. Das kostet so viel Zeit.

Kieferer · ‎16.02.2022

Sieht so aus das der OFDMA nicht richtig arbeitet. Das delta zu den QAM Kanälen ist zu gering. Der OFDMA muß brüllen um verstanden zu werden. Dementsprechend erhöht auch das Rauschen.

3dB bedeuten eine Verdoppelung der Leistung. -> Log10= P_1/P_2

Erklärung

https://forum.vodafone.de/t5/St%C3%B6rungsmeldungen-Internet-TV/Kann-Vodafone-Internet/m-p/2791179#M...

"Bei SC-QAM haben wir eine Kanalbreite von 6,4 MHz bei OFDMA 1,6 MHz, dadurch entsteht ein sogenannter Backoff. Bedeutet, bei der OFDMA Pegelmessung per ONX bezieht sich das Messergebnis auf die Messbandbreite von 1,6 MHz, dadurch wird der Pegel um -6dB niedriger im Vergleich zu den SC-QAM Trägern im Upstream dargestellt."

https://forum.vodafone.de/t5/St%C3%B6rungsmeldungen-Internet-TV/Kann-Vodafone-Internet/m-p/2791179#M442412 "Bei SC-QAM haben wir eine Kanalbreite von 6,4 MHz bei OFDMA 1,6 MHz, dadurch entsteht ein sogenannter Backoff. Bedeutet, bei der OFDMA Pegelmessung per ONX bezieht sich das Messergebnis auf die Messbandbreite von 1,6 MHz, dadurch wird der Pegel um -6dB niedriger im Vergleich zu den SC-QAM Trägern im Upstream dargestellt."

Die einzige Lösung, die auch bei mir funktionierte, ist das abdrehen des OFDMA Kanals.

Das kann nur VF.

"Downstream ist von Sekunde 0 schlecht (konstant 5 Mbps). Keine Veränderung auch nach Stunden."

Es kann nicht die Aufgabe des Kunden sein mit iperf3 nachzuweisen das was nicht stimmt.

Speedtests sind dafür wenig geeignet.

Mit iperf3 -c iperf.par2.as49434.net -p9210 -t900 -V

führts du einen Test für 900s aus. Ggf. mußt du den Port 9210 ändern.

Unter iperf.fr findest du näheres.

OT

Wie bereits von mir vermutet ist der nicht funktionierender OFDMA Kanal die Ursache, gepaart mit einem Casa CMTS hat VF den OFDMA nicht im Griff.

Erstaunlich viele - und beständig mehr - Kunden klagen über einen schlechten Upload. Der OFDMA wurde im Frühling bis Spätsommer ausgerollt.

Nur ein Bruchteil der Betroffenen melden sich hier zu Wort, meist sind es Kunden aus dem Homeoffice die Ewigkeiten brauchen Files hochzuladen, Kunden denen die VPN Verbindungen durch dropouts abrauchen, Twitch User und Zocker - aber die jammern immer.

Die Lösung von VF besteht darin einen Techniker zu schicken. Meist wird nichts gefunden, dennoch kommt es zu Folgeaufträgen. Alternativ kommt ein Routertausch. Auch dieses Pflaster verpufft sehr schnell.

Die Krönung ist die Meldung das ein Rückwegstörer der Verursacher ist. Rückwegstörer gibt es, jedoch haben bei den meisten Kunden vor der Umstellung der Upstream gut funktioniert. Die jetzige Häufung von erkannten Rückwegstörer ist Besorgniserregend.

Der Begriff Rückwegstörer wird mißbraucht. Der VF 3rd Level weiß sicherlich wo der Hase im Pfeffer liegt, kann aber nichts machen. Es ist durchaus möglich dass das Koax Kablenetz an einigen Standorten vergammelt ist, Haus Rückkanalverstärker einen HW upgrade benötigen oder generell neue HW in den Kabelverteilern eingebaut werden muß weil es im OFDMA Kanal zu viel Rauschen gibt und damit zu wenig Nutzsignal anliegt.

Mir als Kunde ist es egal was die Ursache dieses Desasters ist, ich erwarte das es zeitnah für alle Kunden zu einer beständigen Lösung kommt.

Auch ist VF nicht ohne Klimmzüge in der Lage betroffene Kunden vom OFDMA zu befreien. Anscheinend bedarf es viel Handarbeit des 3rd Level den OFDMA Kanal vom CMTS zu lösen.

Warum man kein script aufgesetzt hat um sich von dieser Handarbeit zu befreien, entzieht sich meiner Kenntnis.

OT

Es verdichten sich die Hinweise das Hannes Ametsreiter - VF CEO - für sein Homeoffice einen DSL/GF Anschluß eines alternativen Anbieters nutzt.

Businesskunden wird geraten eine Fallback Lösung von einem alternativen Anbieter anzustreben.

Wie bereits von mir vermutet ist der nicht funktionierender OFDMA Kanal die Ursache, gepaart mit einem Casa CMTS hat VF den OFDMA nicht im Griff.Erstaunlich viele - und beständig mehr - Kunden klagen über einen schlechten Upload. Der OFDMA wurde im Frühling bis Spätsommer ausgerollt. Nur ein Bruchteil der Betroffenen melden sich hier zu Wort, meist sind es Kunden aus dem Homeoffice die Ewigkeiten brauchen Files hochzuladen, Kunden denen die VPN Verbindungen durch dropouts abrauchen, Twitch User und Zocker - aber die jammern immer. Die Lösung von VF besteht darin einen Techniker zu schicken. Meist wird nichts gefunden, dennoch kommt es zu Folgeaufträgen. Alternativ kommt ein Routertausch. Auch dieses Pflaster verpufft sehr schnell. Die Krönung ist die Meldung das ein Rückwegstörer der Verursacher ist. Rückwegstörer gibt es, jedoch haben bei den meisten Kunden vor der Umstellung der Upstream gut funktioniert. Die jetzige Häufung von erkannten Rückwegstörer ist Besorgniserregend. Der Begriff Rückwegstörer wird mißbraucht. Der VF 3rd Level weiß sicherlich wo der Hase im Pfeffer liegt, kann aber nichts machen. Es ist durchaus möglich dass das Koax Kablenetz an einigen Standorten vergammelt ist, Haus Rückkanalverstärker einen HW upgrade benötigen oder generell neue HW in den Kabelverteilern eingebaut werden muß weil es im OFDMA Kanal zu viel Rauschen gibt und damit zu wenig Nutzsignal anliegt. Mir als Kunde ist es egal was die Ursache dieses Desasters ist, ich erwarte das es zeitnah für alle Kunden zu einer beständigen Lösung kommt. Auch ist VF nicht ohne Klimmzüge in der Lage betroffene Kunden vom OFDMA zu befreien. Anscheinend bedarf es viel Handarbeit des 3rd Level den OFDMA Kanal vom CMTS zu lösen.Warum man kein script aufgesetzt hat um sich von dieser Handarbeit zu befreien, entzieht sich meiner Kenntnis. OTEs verdichten sich die Hinweise das Hannes Ametsreiter - VF CEO - für sein Homeoffice einen DSL/GF Anschluß eines alternativen Anbieters nutzt.Businesskunden wird geraten eine Fallback Lösung von einem alternativen Anbieter anzustreben.

Ob eine AVM Docsis 3.1 SchwitzBox oder die Pastikbomber von VF, das Upload Problem wird dadurch nicht gelöst.

Viele die mit einem CASA CMTS mit aufgeschalteten OFDMA angebunden sind haben diesen Problem. CMTS check hier.

Tante Erna und Onkel Hubert die nur ein wenig surfen bemerken keinen Unterschied.

Das Ziel der Umstellung auf den OFDMA Kanlal ist es 100MBits im Upoad zu erreichen. VF rudert aber wieder zurück, hier und hier (ohne Gewähr) weil es nicht geht.

Wir - die VF Kunden - können nur mutmaßen und die Mods halten sich sehr bedeckt.

Also stochere ich mal im Nebel:

Schaue dir das mal an, besonders der Abschnitt tdma. Und jetzt stelle dir vor das der SNR/MER im Up - den der Kunde nicht sieht - nicht besonders gut ist oder zuviele Modems im Segment (@200MBits im Segment???) hängen und die komplexe Fehlerkorrekur nicht zeitgerecht den vom CMTS zugewiesenen Timeslot trifft.

Dann kommt es sicherlich zu den festgestellten Effekten - tcp retries, Verkleinerung des cwnd, weniger speed das CMTS kurz vor dem overload.

Aber nix genaues weiß man nicht.

Der 3rd Level schiebt nun Überstunden, weil dieser mit "Hochdruck" das Problem der Marketingstrategen lösen muß.

Diesbezüglich sind hunderte von Störungsmeldungen zum Thema Upload sicherlich keine "fake news".

Wir als Kunde können gar nichts machen

Ob eine AVM Docsis 3.1 SchwitzBox oder die Pastikbomber von VF, das Upload Problem wird dadurch nicht gelöst. Viele die mit einem CASA CMTS mit aufgeschalteten OFDMA angebunden sind haben diesen Problem. CMTS check hier. Tante Erna und Onkel Hubert die nur ein wenig surfen bemerken keinen Unterschied. Das Ziel der Umstellung auf den OFDMA Kanlal ist es 100MBits im Upoad zu erreichen. VF rudert aber wieder zurück, hier und hier (ohne Gewähr) weil es nicht geht.Wir - die VF Kunden - können nur mutmaßen und die Mods halten sich sehr bedeckt. Also stochere ich mal im Nebel:Schaue dir das mal an, besonders der Abschnitt tdma. Und jetzt stelle dir vor das der SNR/MER im Up - den der Kunde nicht sieht - nicht besonders gut ist oder zuviele Modems im Segment (@200MBits im Segment???) hängen und die komplexe Fehlerkorrekur nicht zeitgerecht den vom CMTS zugewiesenen Timeslot trifft.Dann kommt es sicherlich zu den festgestellten Effekten - tcp retries, Verkleinerung des cwnd, weniger speed das CMTS kurz vor dem overload.Aber nix genaues weiß man nicht. Der 3rd Level schiebt nun Überstunden, weil dieser mit "Hochdruck" das Problem der Marketingstrategen lösen muß.Diesbezüglich sind hunderte von Störungsmeldungen zum Thema Upload sicherlich keine "fake news". Wir als Kunde können gar nichts machen

Anscheinend wird auf eine göttliche Eingebung gewartet. Die paranormalen Kräfte der Damen & Herren die auf Ziegen starren haben versagt.

Vor dem sinnfreien Techniker Termin hatte ich den Upload getestet. Alle Zeiten sind in UTC nicht in Localtime.

Der Techniker - weder A**e noch M****s - prüfte den Upload mit ca. 30MBits, jedoch schwankend.

Das deckt sich also mit meinem iperf3 Test. Die Pegel waren wie erwartet OK.

Nach dem Test hatte er den Support angerufen, ich mußte einer anderen Tätigkeit nachgehen. Den Inhalt des Gesprächs ist mir nicht bekannt. Auffällig war, das selbst der Techniker minutenlang in der Warteschleife war.

Trotz alledem hat er sich nochmals die Installation angeschaut und mit einem Kabeltester am HÜP die Reflexionen gemessen. Nichts auffälliges, alles OK. Er bemerkte mit seinen Handheld das Kanäle im up ihre Modulation änderten.

Guter Techniker, kam aus wahrscheinlich aus Bulgarien.

Er zog dann zum nächsten englischen Patienten weiter.

Nicht müde zog ich den nächsten Test durch. Zuerst mit den herkömmlichen Speedtests dann mit iperf3.

Halejulia, der upload geht. Zuerst habe ich die docsis werte angeschaut, ups kein OFDMA mehr, wie das?

Haben etwa die auf Ziegen starrenden Damen&Herren eine Ziege zum umfallen gebracht?

Nun bin ich davon überzeugt das es paranormale Kräfte gibt.

Den OFDMA bekam man nicht weg, nun doch?

Upstream-Kanäle
Kanal ID Kanaltyp Frequenz (MHz) Modulation Send. Signalstärke (dBmV/dBµV) Ranging Status
1 SC-QAM 51 64QAM 47/107 Erfolgreich
4 SC-QAM 31 64QAM 47/107 Erfolgreich
3 SC-QAM 37 32QAM 47/107 Erfolgreich
2 SC-QAM 45 64QAM 47/107 Erfolgreich
Ich kann nicht ausschließen das die neue Firmware positive Vibrations ausstrahlt hat und mich vom OFDMA Desaster befreit hat.

Firmware-Version AR01.04.046.09_100721_7245.PC20.10.X1
Firmware-Version: 01.04.046.09.EURO.PC20

Produkt name: Vodafone Docsis 3.1

Speedtests

Der Langzeit ipfer3 Test, kann nicht ganz überzeugen, aber gut annehmbar.

Anscheinend wird auf eine göttliche Eingebung gewartet. Die paranormalen Kräfte der Damen & Herren die auf Ziegen starren haben versagt.Vor dem sinnfreien Techniker Termin hatte ich den Upload getestet. Alle Zeiten sind in UTC nicht in Localtime. Der Techniker - weder A**e noch M****s - prüfte den Upload mit ca. 30MBits, jedoch schwankend.Das deckt sich also mit meinem iperf3 Test. Die Pegel waren wie erwartet OK. Nach dem Test hatte er den Support angerufen, ich mußte einer anderen Tätigkeit nachgehen. Den Inhalt des Gesprächs ist mir nicht bekannt. Auffällig war, das selbst der Techniker minutenlang in der Warteschleife war. Trotz alledem hat er sich nochmals die Installation angeschaut und mit einem Kabeltester am HÜP die Reflexionen gemessen. Nichts auffälliges, alles OK. Er bemerkte mit seinen Handheld das Kanäle im up ihre Modulation änderten.Guter Techniker, kam aus wahrscheinlich aus Bulgarien. Er zog dann zum nächsten englischen Patienten weiter. Nicht müde zog ich den nächsten Test durch. Zuerst mit den herkömmlichen Speedtests dann mit iperf3.Halejulia, der upload geht. Zuerst habe ich die docsis werte angeschaut, ups kein OFDMA mehr, wie das?Haben etwa die auf Ziegen starrenden Damen&Herren eine Ziege zum umfallen gebracht?Nun bin ich davon überzeugt das es paranormale Kräfte gibt.Den OFDMA bekam man nicht weg, nun doch?Upstream-KanäleKanal ID Kanaltyp Frequenz (MHz) Modulation Send. Signalstärke (dBmV/dBµV) Ranging Status1 SC-QAM 51 64QAM 47/107 Erfolgreich4 SC-QAM 31 64QAM 47/107 Erfolgreich3 SC-QAM 37 32QAM 47/107 Erfolgreich2 SC-QAM 45 64QAM 47/107 ErfolgreichIch kann nicht ausschließen das die neue Firmware positive Vibrations ausstrahlt hat und mich vom OFDMA Desaster befreit hat.Firmware-Version AR01.04.046.09_100721_7245.PC20.10.X1Firmware-Version: 01.04.046.09.EURO.PC20Produkt name: Vodafone Docsis 3.1 Speedtests Der Langzeit ipfer3 Test, kann nicht ganz überzeugen, aber gut annehmbar.

Userban wg. wiederholter Missachtung der Forenregeln. Gruß, das Mod-Team