Unitymedia TC4400 - nach CMTS-Wechsel Packet Loss, Ping und Datentransferrate unterirdisch

[Wechseler]

Ich habe zwar schon im inoffiziellen PYUR-Forum gepostet, aber dort liest eh keiner. Nach einem CMTS-Wechsel bei PYUR sieht meine Leitung so aus:


Die Modemwerte sehen IMHO hervorragend aus:


Der Ping ist abgrundtief schlecht, 35 ms zum ersten Hop, dazu kommt kräftig Packet Loss und von den gebuchten 200 Mbps werden nur durchschnittlich 120 Mbps erreicht.

Hier ein Beispiel (Google-DNS):

64 bytes from 8.8.8.8: seq=0 ttl=58 time=50.962 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=49.785 ms
64 bytes from 8.8.8.8: seq=2 ttl=58 time=52.496 ms
64 bytes from 8.8.8.8: seq=3 ttl=58 time=54.658 ms
64 bytes from 8.8.8.8: seq=4 ttl=58 time=53.902 ms
64 bytes from 8.8.8.8: seq=5 ttl=58 time=53.327 ms
64 bytes from 8.8.8.8: seq=6 ttl=58 time=52.616 ms
64 bytes from 8.8.8.8: seq=7 ttl=58 time=53.192 ms
64 bytes from 8.8.8.8: seq=8 ttl=58 time=52.773 ms
64 bytes from 8.8.8.8: seq=9 ttl=58 time=53.076 ms
64 bytes from 8.8.8.8: seq=10 ttl=58 time=52.828 ms

Wenn ich jetzt parallel dazu ordentlich Last auf der Strippe mache, dann sollte der Ping ja eigentlich raufgehen, denn schließlich laufen die Puffer voll.
Bei mir geht der Ping dann aber runter:

64 bytes from 8.8.8.8: seq=0 ttl=58 time=45.153 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=54.170 ms
64 bytes from 8.8.8.8: seq=2 ttl=58 time=47.104 ms
64 bytes from 8.8.8.8: seq=3 ttl=58 time=44.815 ms
64 bytes from 8.8.8.8: seq=4 ttl=58 time=44.688 ms
64 bytes from 8.8.8.8: seq=5 ttl=58 time=45.362 ms
64 bytes from 8.8.8.8: seq=6 ttl=58 time=35.114 ms
64 bytes from 8.8.8.8: seq=7 ttl=58 time=42.313 ms
64 bytes from 8.8.8.8: seq=8 ttl=58 time=59.654 ms
64 bytes from 8.8.8.8: seq=9 ttl=58 time=33.910 ms
64 bytes from 8.8.8.8: seq=10 ttl=58 time=44.606 ms
64 bytes from 8.8.8.8: seq=11 ttl=58 time=39.898 ms
64 bytes from 8.8.8.8: seq=12 ttl=58 time=48.271 ms
64 bytes from 8.8.8.8: seq=13 ttl=58 time=46.981 ms
64 bytes from 8.8.8.8: seq=14 ttl=58 time=38.196 ms

Häää? :kratz:

Das widerspricht allem, was ich über TCP/IP-Implementierungen weiß. Was zum Teufel geht da vor?

 

[Menano]

Was für ein CMTS ist das denn?

Wenn ich jetzt parallel dazu ordentlich Last auf der Strippe mache, dann sollte der Ping ja eigentlich raufgehen, denn schließlich laufen die Puffer voll.
Bei mir geht der Ping dann aber runter:

Das konnte ich bei Unitymedia an einem CASA CMTS auch schonmal beobachten. Wenn man viele Verbindungen (300+) aufmacht dann geht der Ping runter.

 

[why_]

Das widerspricht allem, was ich über TCP/IP-Implementierungen weiß. Was zum Teufel geht da vor?

Shared Medium. Ich kann mir vorstellen das dir da schlicht häufiger Zeitschlitze zugeordnet werden, da häufiger Daten von und zu dir gehen und somit nicht gewartet wird bis der Puffer voll ist, bzw. der häufiger voll ist. Aber so wirklich genau kann dir das wohl nur PYUR sagen, eventuell nicht mal die da die die Logic im CMTS nicht gut genug kennen und dir das dann wirklich nur noch der CMTS Hersteller sagen kann, was die da intern für eine Magie fahren.

 

[rv112]

Wurde das CMTS erst getauscht? Bei mir hat es nach dem Upgrade 2 Wochen gedauert bis die Leitung wirklich sauber lief. Die sehen das ja auch wenn es da Probleme mit Kunden gibt und arbeiten dann dran.

 

[Wechseler]

Wurde das CMTS erst getauscht?

Vor einer Woche. Ich habe heute mal das olle TC7200 von PYUR drangehängt, um den Verdacht vom "Kundenmodem" zu nehmen und zu sehen, ob dieses auch Packet Loss produziert.

Das TC7200 bekommt aber überhaupt keinen Sync mehr hin:

Time Not Established Critical (3) No Maintenance Broadcasts for Ranging opportunities received ... Time Not Established Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/Q... Time Not Established Warning (5) DHCP WARNING - Non-critical field invalid in response ;CM-MAC... Time Not Established Notice (6) Honoring MDD; IP provisioning mode = IPv4 Time Not Established Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/Q... Time Not Established Warning (5) Lost MDD Timeout;CM-MAC=xx:xx:xx:xx:xx:xx;CMTS-MAC=00:00:00:0...

Selbst wenn es nicht mehr provisioniert sein sollte (normalerweise bleibt bei PYUR das Leihmodem drin, auch mit Kundengerät), sollte es doch trotzdem einen Sync hinbekommen, oder?

 

[rv112]

Ja klar.

 

[Wechseler]

Ja klar.

Dann ist also das TC4400 der Grund, warum ich überhaupt noch online bin. :glück:

Nur die 200 Mbps sind leider weg. :traurig:

 

[Torsten1973]

Dann solltest du eine Störung melden, Wechseler.

 

[rv112]

Ich sagte glaub schon mal, dass ich mit dem TC4400 teils noch online war, wo jede Connectbox schon abgeschmiert war.

 

[Wechseler]

Dann solltest du eine Störung melden, Wechseler.

Hab ich schon am Montag, bisher ist noch nichts passiert.

Ich sagte glaub schon mal, dass ich mit dem TC4400 teils noch online war, wo jede Connectbox schon abgeschmiert war.

Es scheint ein regelrechtes Wundermodem zu sein.

 

[Wechseler]

Hat jemand eine Idee, wie man prüfen kann, ob der Packet-Loss auf dem Vorwärts- oder Rückwartsweg auftritt?

 

[Menano]

Ja. Mit Teamspeak

 

[Wechseler]

Ich habe heute mal das olle TC7200 von PYUR drangehängt, um den Verdacht vom "Kundenmodem" zu nehmen und zu sehen, ob dieses auch Packet Loss produziert.

So, das Teil hat jetzt endlich mal einen Sync hinbekommen, Leitungswerte sehen ziemlich genauso aus wie mit dem TC4400:


Das KNB-Leihmodem ist natürlich nicht mehr provisioniert und läuft mit einer 96kbps-Konfigurationsdatei ohne Internetzugriff. Der Nameserver von PYUR läßt sich aber trotzdem pingen, so daß ich den Packet Loss damit testen kann.

 

[Andreas1969]

Der Nameserver von PYUR läßt sich aber trotzdem pingen, so daß ich den Packet Loss damit testen kann.

Und, ha'ste Packet Loss mit dem Teil ?

 

[Wechseler]

Und, ha'ste Packet Loss mit dem Teil ?

Nicht nennenswert:

<i>
</i>--- 217.68.161.141 ping statistics ---
3001 packets transmitted, 2993 packets received, 0% packet loss
round-trip min/avg/max = 31.370/36.232/137.815 ms

Der Ping ist auf jeden Fall gleichermaßen besch... :nein:

Ich mache gerade nochmal den Gegentest mit dem TC4400 ohne Traffic auf der Verbindung. Allerdings sind die Verhältnisse ohne Provisionierung und mit nur 8 Downstream-Kanälen (Limit des TC7200) nicht richtig vergleichbar.

Andererseits will ich jetzt auch mein eigenes Modem nicht wieder rauswerfen lassen, da dessen manuelle Aktivierung ein ziemlicher Stunt war.

 

[Wechseler]

Gegentest mit dem TC4400:

--- 217.68.161.141 ping statistics ---
3000 packets transmitted, 2989 packets received, 0% packet loss
round-trip min/avg/max = 30.904/35.950/74.854 ms

Beim Packet Loss also kaum ein Unterschied. Das war schon mal schlimmer.

Geschwindigkeit kommt aber trotzdem nie mehr über 150 Mbps hinaus

 

[robert_s]

Und, ha'ste Packet Loss mit dem Teil ?

Nicht nennenswert:

<i>
</i>--- 217.68.161.141 ping statistics ---
3001 packets transmitted, 2993 packets received, 0% packet loss
round-trip min/avg/max = 31.370/36.232/137.815 ms

Aber trotzdem nicht in Ordnung. Wenn ich diese Adresse von meinem Vodafone Kabel Anschluss aus anpinge:

<i>
</i>--- 217.68.161.141 ping statistics ---
3000 packets transmitted, 3000 received, 0% packet loss, time 42682ms
rtt min/avg/max/mdev = 10.896/17.474/42.724/2.749 ms

Also der Antwortet schon auf jeden Ping, selbst aus "fremden" Netzen. Dann sollte da im eigenen Netz erst recht alles ankommen.

 

[Wechseler]

Aber trotzdem nicht in Ordnung. Wenn ich diese Adresse von meinem Vodafone Kabel Anschluss aus anpinge:

<i>
</i>--- 217.68.161.141 ping statistics ---
3000 packets transmitted, 3000 received, 0% packet loss, time 42682ms
rtt min/avg/max/mdev = 10.896/17.474/42.724/2.749 ms

Also der Antwortet schon auf jeden Ping, selbst aus "fremden" Netzen. Dann sollte da im eigenen Netz erst recht alles ankommen.

Das liegt natürlich daran, daß das "fremde" Netz besser funktioniert.

Bei mir war das allerdings ein Test über fast eine Stunde, nicht über 43 Sekunden. Da hatte ich beim letzten Versuch vor rund zwei Wochen noch über 1 % Loss.

 

[Wechseler]

Default-Gateway mit "adaptive ping":

1000 packets transmitted, 1000 received, 0% packet loss, time 27683ms
rtt min/avg/max/mdev = 14.684/28.073/58.656/8.983 ms, pipe 2, ipg/ewma 27.710/27.644 ms

Oder mit speedtest.tele2.net:

--- 90.130.70.73 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 47037ms
rtt min/avg/max/mdev = 25.553/47.011/57.240/2.311 ms, pipe 2, ipg/ewma 47.084/46.348 ms

Geht also alles durch, der Packet Loss tritt nur über längere Zeiträume sporadisch auf.

 

[Wechseler]

Nach der Wiederkehr der Rückwegausfälle bin ich jetzt aufgefordert worden, das TC7200.20 bis zur Entstörung wieder anzuschließen. Hängt jetzt dran, synct (und hat natürlich keinen Internetzugriff).

 

[Samsungstory]

Mit welcher Begründung den?

 

[Wechseler]

Mit welcher Begründung den?

Ohne Begründung. Obwohl das Problem ja klar nichts mit dem Endgerät zu tun hat.

 

[robert_s]

Mit welcher Begründung den?

Ich würde mal sagen, weil man das providereigene Gerät per Fernabfrage zur Fehlerdiagnose nutzen kann und das kundeneigene wohl nicht dafür nutzen kann oder will.

 

[Wechseler]

Ich würde mal sagen, weil man das providereigene Gerät per Fernabfrage zur Fehlerdiagnose nutzen kann und das kundeneigene wohl nicht dafür nutzen kann oder will.

Leider hab ich keine zweite Kabeldose, sonst könnte ich das Leihmodem parallel anschließen. :zerstör:

 

[sparkie]

zur Not tut's da aber auch ein T-Stueck :smile:

ich hatte heute bis knapp 23:00 Uhr auch einen kurzen Ausfall. Im Auslastungsmesstool von hier sieht es dann so aus:




das Programm funktioniert ganz gut inzwischen. Ich hoffe ich komme heute dazu den Nachbau zu beschreiben...