"Internetausfall" - Ursache Ethernetkabel/Router?

Tungon schrieb:
einfach mit dem Handy im LTE Netz
Ja zum Beispiel.

Ping raus funktioniert bei dir?
Kannst im Eingabefenster ja mal testen mit ping -4 computerbase.de und ping -6 computerbase.de

Ich schreibe das, weil Vodafone hier bei mir zwischendurch große Probleme hat. Deshalb monitore ich meine IP v4 und v6 Adresse.
 
Verlegte Kabel werden nicht direkt angeschlossen. Da kommen Dosen dazwischen. Die Idee dahinter ist, dass die Kabel nicht mehr bewegt werden. Bewegteile sind Verschleißteile.
Diese ganz dünnen Kabel sind besonders anfällig für Bewegungen.
Über die Schirmung kann ich nichts sagen. Das Kabel an sich ist ein China Generikum (das muss erstmal nichts schlimmes sein).
 
Wobei das bei uns Zuhause eher auf die v4 Adresse zutrifft mit den Problemen. IPv6 läuft sauber.
Hier mal zwei Bilder zu Veranschaulichung. Von einem auf den anderen Tag.

6590-15.03.21-v4.png

6590-16.03.21-v4.png
 
motorazrv3 schrieb:
Ja zum Beispiel.

Ping raus funktioniert bei dir?
Kannst im Eingabefenster ja mal testen mit ping -4 computerbase.de und ping -6 computerbase.de

Ich schreibe das, weil Vodafone hier bei mir zwischendurch große Probleme hat. Deshalb monitore ich meine IP v4 und v6 Adresse.
Okay, ich behalte das mal im AUge.
TriggerThumb87 schrieb:
Verlegte Kabel werden nicht direkt angeschlossen. Da kommen Dosen dazwischen. Die Idee dahinter ist, dass die Kabel nicht mehr bewegt werden. Bewegteile sind Verschleißteile.
Diese ganz dünnen Kabel sind besonders anfällig für Bewegungen.
Über die Schirmung kann ich nichts sagen. Das Kabel an sich ist ein China Generikum (das muss erstmal nichts schlimmes sein).
Okay. Wenn ich das Kabel nun austausche, verlege ich es in einem Kabelkanal. Also diesmal ohne Kleber.
 
Und die Biegeradien beachten (zumindest rudimentär), d. h. keine harten 90° Knicke,aber das sollte selbstverständlich sein.
 
  • Gefällt mir
Reaktionen: Tungon
Ein Kabel hat keine Auswirkungen auf die Latenz eines Ping. Entweder der Ping kommt an und wird beantwortet oder nicht. Es gibt keine "langsamen Kabel". Ein defektes Kabel kann nur dazu führen, dass Pings bzw deren Antworten fehlerhaft sind und gar nicht ankommen. Ein Timeout ist aber nicht gleichbedeutend mit so einem defekten Ping-Paket, weil das Windows Ping-Tool ein 4 Sekunden Zeitfenster hat und alles, was länger dauert, wird als verloren gezählt, auch wenn es nach 4001 ms ankommt. Ein defekter Ping durch einen Wackelkontakt o.ä. im Kabel kommt aber nie an.

Soviel erstmal zur Kabeltheorie. Warum nun also die Schwankungen beim Ping? Die Ursache für Verzögerungen bei einem Ping ist stets auf eine oder mehrere der aktiven Komponenten auf der Strecke zurückzuführen. Überall dort wo ein Paket aktiv verabeitet wird. Bei einer direkten Kabelverbindung zwischen Quelle und Ziel sind das demnach auch nur diese selbst. In 99% aller Fälle ist das Ziel dafür verantwortlich, weil dieses bei der Bearbeitung und Beantwortung des Pings zu lange braucht, beispielsweise weil es in irgendeiner Form überlastet ist oder gar bewusst die Antwort verzögert, um Ressourcen zu schonen.

Mach als Gegenprobe mal einen Ping auf einen anderen PC/Laptop.
 
Raijin schrieb:
Ein Kabel hat keine Auswirkungen auf die Latenz eines Ping.

ICMP hat niedrigere Priorität als TCP/UDP. Die Latenz kann sich also auch dadurch erklären lassen, dass an der Leitung ein Engpass vorliegt oder andere Störungen im Kabel, die dazu führen, dass niedrig priorisierter Datenverkehr erstmal nicht beantwortet/gesendet wird.
Oder missverstehe ich da etwas?
 
Und was hat das mit dem Kabel zu tun? Das Kabel überträgt nur die physischen Bits durch elektrische Impulse, hat aber keine Ahnung ob das jetzt TCP, ICMP oder ABC, SPD, CDU, MFG, HDCP, MDI, TKKG, BASF, UDP, SQL oder XYZ ist. Ein Kabel priorisiert nichts, es überträgt sogesehen nur 0en und 1en und das tut es mit derselben Geschwindigkeit. Die Latenz des Kabels selbst resultiert aus dessen elektrischen Eigenschaften und die sind konstant bzw werden nur durch Störungen bzw. die Länge beeinflusst.

Wenn der Ping schwankt, liegt das an Verzögerungen bei der Bearbeitung des ICMP Echo Requests bzw dessen Reply. Das Kabel pumpt nur stur Bits von A nach B und das tut es für alle Bits mit derselben Geschwindigkeit.



Es kann Unterschiede zwischen Kabeln geben, aber auch nur dann, wenn das Kabel die Spezifikationen nicht erfüllt, also beispielsweise nicht die offiziellen Vorgaben und Grenzwerte für Cat5/6/7 einhält. Das kann bei billigem CCA-Kabel der Fall sein, das eben nicht aus reinem Kupfer besteht, sondern lediglich aus Aluminium mit Kupferbeschichtung. Aber auch hier gilt: Jedes Bit wird über dasselbe Kabel gleich schnell übertragen. Etwaige Schwankungen entstehen im Sender/Empfänger und sind unabhängig vom Kabel.


Das hat im übrigen nichts mit der Übertragungrate zu tun. Schlechtes CCA-Kabel kann durchaus dazu führen, dass keine vollen 1 Gbit/s erreicht werden, weil durch die veränderten elektrischen Eigenschaften des Kabels bei der Fehlerkorrektur im NIC Pakete womöglich als fehlerhaft verworfen werden könnten. Bei TCP werden diese Pakete erneut gesendet und in der Folge sinkt die Netto-Übertragungsrate. Die Latenz, also der Ping, bleibt aber dieselbe und ein ICMP-Paket kommt nur entweder an oder nicht, weil es keine Retransmission gibt wie eben bei TCP. Der Ping wäre also einfach weg und nicht zwischendrin mal höher oder niedriger, also nicht im Bezug auf das Kabel.
 
Zuletzt bearbeitet:
Ich glaube wir missverstehen uns da.
Es hat insofern mit dem Kabel zu tun, weil hier nicht nur ICMP gesendet wird, sondern auch andere Daten über andere Protokolle, die eine höhere Priorität haben. Meine Frage war, ob es bei Daten, die neugesendet werden müssen, zu höherer Latenz kommen kann (ich sage ja auch nicht, dass sich die physikalische Übertragungsdauer ändert), weil andere höherprioritisierte Daten aufgrund von Neuübertragung in der Pipeline stecken bleiben.
Du sprichst ja Neuübertragungen selber in deinem letzten Absatz an. Meine Frage ist, ob dann da die arme ICMP-Anfrage warten muss.
Er hat nunmal entsprechendes Verhalten nur mit dem einen Kabel.
Daher meine Frage(!)
Kein Grund mich jetzt mit Abkürzungen zu ertränken. :(

Ich weiß auch nicht wie sich die Fritzbox verhält, wenn ein Kabel Probleme macht.
 
Das hat aber immer noch nichts mit dem Kabel zu tun. Wenn das Betriebssystem, dessen Netzwerkstack, der Treiber oder der NIC selbst priorisiert bzw das Queuemanagement (Stichwort: QoS) Paket X oder Y als erstes auf die Leitung bzw ins Kabel schickt, dann ist das eben so. Mit dem Kabel hat das aber nichts zu tun, weil das Kabel gar nicht weiß was es da gerade überträgt.
 
Ich frage mal Stück für Stück.
Und wenn das Kabel in dem Moment Übertragungsfehler hat und deshalb das ICMP Paket warten muss, bis wichtigere Datenpakete endlich fehlerfrei gesendet werden können?
 
Nix wartet. Der NIC schickt ein Signal in den Port und von dort geht es über den Stecker direkt ins Kabel. Wenn bei ICMP Übertragungsfehler auftreten, das losgeschickte Paket beim Empfänger also defekt ankommt (zB Checksumme stimmt nicht, o.ä.), dann wird das Paket am Ziel verworfen und der Ping schlägt fehl. Keine Verzögerung, sondern gar nix.

Die vermeintliche Tatsache, dass ein Kabeltausch hilft, ist insbesondere aufgrund der Schwankung dennoch auf den NIC zurückzuführen, weil das Kabel ein einmal abgeschicktes Bit bzw. Paket immer mit derselben Geschwindigkeit überträgt. Es kann sicherlich sein, dass die Fehlerkorrektur im NIC für Verzögerungen verantwortlich ist, aber das Kabel kann an anderer Stelle und zwischen anderen Geräten trotzdem 1A funktionieren.
 
Ich rede auch immer noch nicht von Übertragungsfehlern beim ICMP Paket, sondern bei anderen Paketen, die davor gesendet worden sind, und nochmals übertragen werden müssen aufgrund von Fehlern. Wartet dann das ICMP Paket?

Raijin schrieb:
Es kann sicherlich sein, dass die Fehlerkorrektur im NIC für Verzögerungen verantwortlich ist, aber das Kabel kann an anderer Stelle und zwischen anderen Geräten trotzdem 1A funktionieren.

Das alleine reicht mir eigentlich schon als Bestätigung wieso es "am Kabel" liegt.
 
Zuletzt bearbeitet:
TriggerThumb87 schrieb:
Wartet dann das ICMP Paket?
Nein. Zu sendende Pakete werden in die Warteschlange eingereiht und wenn sie dran sind, werden sie abgeschickt. Je nach Queuemanagement gibt es nur eine oder ggfs sogar Dutzende Warteschlangen.



TriggerThumb87 schrieb:
Das alleine reicht mir eigentlich schon als Bestätigung wieso es "am Kabel" liegt.
Würde die Fehlerkorrektur über 30ms dauern, für ein einzelnes Paket, ist das aber de facto ein Problem des NIC.


Wie dem auch sei, glaub was du willst.
 
Zurück
Oben