Massives Verbindungsproblem mit Hitron

[beta_tester]

Region München

Code: Alles auswählen

Vendor Hitron Technologies 
Model CVE-30360 
Hardware Version 1B 
Firmware Version 4.2.8.15-IMS-KDG 
Boot Version PSPU-Boot 1.0.16.22-H2.9.1 

Ich habe bereits ein Ticket bei KD offen. Mir wurde ein neues Coax Kabel geschickt. Das Problem besteht weiterhin.

Problem:
Sobald die Leitung ausgelastet ist (1mbit up oder 25mbit down) wird die Verbindung unbenutzbar.
Es kommt die Hohen Latenzen und Verbindungsabbrüchen.

Das Problem tritt mit angeschlossenem Lan Kabel (wlan natürlich augeschaltet) und per wlan auf.

Wlan

Code: Alles auswählen

Antwort von 8.8.8.8: Bytes=32 Zeit=1277ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=1609ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=1286ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=1968ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2671ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=666ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=1053ms TTL=57
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=2972ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=1057ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2991ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2057ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2286ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2149ms TTL=57

Wenn ich die gleiche Last erzeuge aber mit Lan angeschlossen bin:

Code: Alles auswählen

C:\Users\Admin>ping -t 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=225ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=211ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=209ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=220ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=232ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=226ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=214ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=242ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=213ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=234ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=1953ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=972ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=1412ms TTL=57
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=3856ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=3479ms TTL=58
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=2902ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=3012ms TTL=58
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=3088ms TTL=58
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=3927ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=3520ms TTL=58
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=3060ms TTL=57
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=3657ms TTL=58
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=2981ms TTL=58
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=2911ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=2442ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=3375ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=701ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=2070ms TTL=58
Zeitüberschreitung der Anforderung.

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 50, Empfangen = 28, Verloren = 22
    (44% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 209ms, Maximum = 3927ms, Mittelwert = 1840ms

Mir ist schon klar, dass die Verbindung schlechter wird aber so massive Abbrüche?


edit:

Ganz vergessen:
die Verbindung zum Modem ist ausgezeichnet während den Problemen:

Code: Alles auswählen

C:\Users\Admin>ping -t 192.168.0.1

Ping wird ausgeführt für 192.168.0.1 mit 32 Bytes Daten:
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.0.1: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.0.1:
    Pakete: Gesendet = 39, Empfangen = 39, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
STRG-C

[ externes Bild ]

edit 2:

ohne last hab ich eine Super Verbindung:

Code: Alles auswählen

C:\Users\Admin>ping -t 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=174ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=14ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=13ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=15ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=14ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=13ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=13ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=15ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=14ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=15ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=19ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=22ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=14ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=23ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=23ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=13ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=14ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=57

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 30, Empfangen = 30, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 174ms, Mittelwert = 19ms

[reneromann]

Was erwartest du denn, wenn du die Leitung ans Limit treibst?
Sollen die Ping/ICMP-Pakete (sind ja immerhin auch Daten!) etwa priorisiert gegenüber "normalem" Traffic durchgeleitet werden?
Derzeit stellen sich die ICMP-Pakete in die gleiche Warteschleife, in der auch dein "normaler" TCP-Traffic ist - und je dichter du an's Limit gehst, desto weniger Platz bleibt für die ICMP-Pakete und damit steigt die RTT an. Das ist völlig normal.

[Abraxxas]

Sobald die Leitung ausgelastet ist (1mbit up oder 25mbit down) wird die Verbindung unbenutzbar.

Sobald der Eimer voll ist passt nix mehr rein. Logisch, oder?

[beta_tester]

Also ist es eurer Ansicht nach völlig normal, das es massive Verbindungsabbrüche gibt?
Ich habe das gleiche bei einer Unitymedia und einer Telekomleitung getestet. Dort hatte ich keinerlei Abbrüche.
Auch die Kundenhotline meinte zwar, dass die Latenz höher wird aber Abbrüche sollte es keine geben.

[DarkStar]

Normal ist das Sicherlich nicht.
Ich habe eben gerade mal eine Ping laufen lassen und gleichzeitig einen Speedtest gemacht.
Der Ping zu Google lag die meiste Zeit genauso niedrig wie ohne Down/Upload Belastung 19-22ms. 2-3 mal gab es Spikes auf 690ms.

[beta_tester]

Danke! Das ist auch meine Erfahrung! Also macht es schon Sinn einen Techniker kommen zu lassen? Kann ich noch etwas testen?

[reneromann]

Was sind für dich "massive Verbindungsabbrüche"?
Doch nicht etwa der Packet Loss beim ICMP-Protokoll / PING...

Das was der Packet Loss beim ICMP-Protokoll (ping) ist, hat NICHTS mit Verbindungsabbrüchen zu tun, sondern lediglich damit, dass die Antworten nicht rechtzeitig genug aufgrund der verstopften Leitung ankommen.
Und wenn die Pakete auch nur eine Millisekunde nach Überschreitung des Timeouts kommen, werden sie die -trotz dessen, dass sie angekommen sind- als verloren angezeigt.

Aber ja, das ist völlig normal - stell's dir mit einer Autobahn vor: Wenn die 2 Spuren stehen und die Bahn dicht ist, dann kommen deine IMCP/Ping-Pakete [sprich ein "normales" Auto] auch nicht schneller von A nach B als sich hinten anzustellen und zu warten. Nur sagt dein Rechner: Wenn der Timeout überschritten ist, ist das Auto nicht (rechtzeitig) angekommen -> Packet Loss. Das hat aber nichts damit zu tun, dass es zu Verbindungsabbrüchen kommt.

Und selbst beim TCP-Protokoll gibt's einen Timeout, in dem ein Antwortpaket SPÄTESTENS eintreffen muss, damit die Verbindung aufrecht erhalten bleibt - sollten durch die Auslastung der Leitung selbst diese Pakete nicht rechtzeitig genug ankommen, kann es beim TCP-Protokoll ebenfalls zu Abbrüchen kommen - dann würde aber auch der Down- oder Upload abbrechen, der die Leitung verstopft.

[reneromann]

Danke! Das ist auch meine Erfahrung! Also macht es schon Sinn einen Techniker kommen zu lassen? Kann ich noch etwas testen?

Der Techniker wird da nichts feststellen - wenn du gerne 99 Euro für nichts bezahlen willst, mach es...
Vielleicht sollest du eher in eine dickere Leitung investieren, wenn du die jetzige ständig ans Limit treibst und mit den Auswirkungen nicht leben kannst.

[beta_tester]

Wenn Dropbox synchronisiert ist der Upload schon voll und ich bekomme massive Probleme. Das surfen wird richtig langsam, telefonieren geht gar nicht.
Wie gesagt ich habe den Vergleich zu anderen Anschlüssen da tritt es nicht auf. Ich würde diejenigen, die behaupten das sei normal, bitten mal einen test zu machen.
Lasst einen speedtest laufen und pingt in der zeit eine internetadresse. Mich würden die Ergebnisse interessieren.

[reneromann]

Wenn Dropbox synchronisiert ist der Upload schon voll und ich bekomme massive Probleme. Das surfen wird richtig langsam, telefonieren geht gar nicht.

Telefonieren, insbesondere bei einem "normalen" Kabel"modem"/"router" sollte vom Internetgeschehen losgelöst sein (sofern es um die "normale" Telefonie am Modem/Router geht und NICHT um VoIP/Skype o.ä. über einen Fremdanbieter.

Wie gesagt ich habe den Vergleich zu anderen Anschlüssen da tritt es nicht auf. Ich würde diejenigen, die behaupten das sei normal, bitten mal einen test zu machen.

Diese Tests bringen nichts, weil das Bild völlig verzerrt ist.
Während bei deiner 25/1-Leitung die ICMP-Pakete keine Lücke mehr finden könnten, könnte dies bei anderen Leuten mit "größeren" Tarifen hingegen kein Problem sein, wodurch die Antwortzeit nicht so extrem ansteigt.
Dies hat aber NICHTS mit Verbindungsabbrüchen zu tun, sondern ist lediglich darauf zurückzuführen, dass die Leitung dicht ist und die Pakete daher zu lange brauchen.

Lasst einen speedtest laufen und pingt in der zeit eine internetadresse. Mich würden die Ergebnisse interessieren.

Wenn du davon sprichst, dass es auftritt, wenn Dropbox synct: Dropbox ist kein Kostverächter, heißt Dropbox krallt sich alles was es kriegen kann.
Dies ist nicht vergleichbar mit einem Speedtest über den Browser! Du könntest aber auch einfach in den Dropbox-Einstellungen die Geschwindigkeit für Up- und Download auf für dich annehmbare Werte begrenzen...