Wie um alles in der Welt kann diese berichtete stundenlange Ping-Zeit real sein?

Ich habe vor kurzem den Osterfeiertag mit meinen Eltern verbracht, die in einer sehr ländlichen Gegend in Großbritannien leben. Sie haben eine (schreckliche) ADSL-Internetverbindung, die über mehrere Kilometer zwielichtigen Kupfers läuft und regelmäßig unterbrochen wird, wenn die Bauern in der Nähe ihre Traktoren in die Telefonleitungen stecken.

Ich bemerkte, dass der Router den pptpHandshake wiederholt ablegte und neu aushandelte, wodurch die Verbindung effektiv unterbrochen wurde. Das war frustrierend. Um nicht verrückt zu werden, forderte ich ihn auf, die minimal akzeptable SNR-Marge und den Handshake für niedrigere Geschwindigkeiten zu verdoppeln:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh


BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.

# adsl configure --snr 200; exit 
Connection closed by foreign host.

Das verbesserte die Sache und das Ding bekam eine (etwas) stabile, wenn auch unglaublich langsame Leitung zur Außenwelt:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

Ungefähr zu diesem Zeitpunkt mischte sich das wirkliche Leben ein und ich verbrachte einige Stunden damit, mit Katzen zu spielen, mir Katzengifs auf meinem Handy anzusehen, tatsächlich mit meiner Familie zu sprechen usw. Ich vergaß, dass ich diesen Ping-Prozess laufen ließ, und kam zurück einen Tag später zu schlagen ctrl-c.

Die zusammenfassende Statistik sagte mir:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

Wie Sie sehen, beträgt die maximale Antwortzeit für ein ICMP-Paket, das einen kurzen transatlantischen Sprung zum DNS-Server von Google durchführt, 3600577,732 ms . Das ist fast genau eine Stunde und sicherlich viel länger als pingdas Standard-Timeout.

Wie um alles in der Welt kann das sein? Ist es richtig? Welcher Router hält ein Paket gerne 60 Minuten lang fest, bevor er es auf seinem Weg sendet? Warum wurde dieses Paket nicht gelöscht? Ist es das Ergebnis eines Überlaufs des 8-Bit-Paketzählers in Kombination mit großen Latenzen?

Abschließend möchte ich wissen, ob es in Großbritannien einen Verhaltenskodex gibt, der besagt, dass für Consumer-ADSL-Verbindungen eine geringere Latenz und ein besseres Verkehrsmanagement erwartet wird als für RFC 1149 und RFC 2549 ;-).

networking routing adsl

— Landak
quelle

Ein Router, der nicht mit Spam überlastet ist.

— Ratschenfreak

Ein gieriger Router;) Ich muss es nur spielen, wenn Sie bemerken, dass eine Stunde gewartet werden soll, bevor das Paket weitergeleitet wird. youtube.com/watch?v=moSFlvxnbgk

— Cestarian

Ist es möglich, dass Ihr Computer, da Sie sagten, dass Sie ihn über Nacht verlassen haben, die +1 Stunde zu Beginn der Sommerzeit angewendet hat und die Berechnung der RTT eines bestimmten Pakets gestört hat?

— Kenkh

@ kenkh - Nope; Ich bin mir auf jeden Fall sicher, dass der Tag, an dem sich die Uhren geändert haben, nicht dieser Tag war. Außerdem kann ich anhand des ping Quellcodes (von ~ l 761) feststellen, dass Zeitzonen in der nachfolgenden Berechnung ignoriert werden ( gettimeofday(nv, NULL)gibt Mikrosekunden in der Epoche zurück). Es hat wirklich eine Stunde gedauert!

— Landak

Wenn Sie Zugriff auf das System haben, können Sie Pathping ausführen? Würde ungefähr zeigen, wo die Verlangsamung ist

— Geselle Geek

Antworten:

Das ICMP-Paket und die Antwort für den Ping sind jeweils 32 Byte lang. Für einen einstündigen Ping hat also jedes Byte fast eine Minute für die Übertragung benötigt.

Dies ist nur durch eine sehr großzügige Anzahl von Wiederholungsfehlern zu erklären (Ihr Vorgehen?), Verbunden mit einem sehr langsamen Router und einem schmerzhaften Warten oder erneuten Versuchen für jedes übertragene Byte.

Das Internet Protocol (IP) überträgt Daten über Datagramme und versucht, keine partiellen zu senden. Nach dem Start der Übertragung wird standardmäßig 200 Millisekunden gewartet, bis dem Datagramm weitere Bytes hinzugefügt wurden. Nach dieser Zeit sendet die Software / Firmware alles, was sie hat, als ein Datagramm. Im Fall der stundenlangen Ping-Zeit kann die Paketnutzlast nur ein Byte betragen haben. Solange noch Daten ankamen, wird die Verbindung von den beiden beteiligten Seiten nicht beendet.

Was du tun kannst :

Wenn andere Telefone, Faxgeräte oder andere Geräte an dieselbe Telefonleitung angeschlossen sind, prüfen Sie, ob sie durch DSL-Filter geschützt sind . Stellen Sie sicher, dass die Leitung zu Ihrem DSL-Modem keinen Filter enthält.
Probieren Sie einen anderen Router aus - sobald Sie ein schlechtes Gerät haben, können Sie nichts weiter tun, als es wegzuwerfen und etwas Besseres zu bekommen.
Wenn kein anderer Router verfügbar ist, wenden Sie sich an Ihren ISP - er kann von seiner Seite aus nützliche Tests durchführen.
Wenn der ISP nichts findet, versuchen Sie trotzdem, einen Ersatz-Router / Modem anzufordern.
Wenn dasselbe Problem bei einem anderen Router auftritt, wenden Sie sich an die Telefongesellschaft.

Es kann ziemlich kompliziert sein, einen problematischen Switch zu finden, wie es bei der Telefongesellschaft der Fall sein kann, aber der ISP verfügt möglicherweise auch über eigene Switches. Normalerweise ist ein Problem mit einem Schalter großflächig, wodurch der fehlerhafte Schalter leichter zu lokalisieren ist. In ländlichen Gegenden, in denen nicht zu viele Teilnehmer diesen Switch verwenden, kann dies jedoch unerkannt bleiben. Wenn einige Nachbarn denselben ISP verwenden, versuchen Sie herauszufinden, wie ihre Verbindung aussieht.

— Harrymc
quelle

Ich würde 2 und 3 umdrehen. Es ist viel einfacher, zuerst den ISP anzurufen. Sie können einen Test machen. Wenn sie Probleme sehen, senden sie ein neues Modem (nicht unbedingt einen Router). Wenn das Problem durch ein neues Modem nicht behoben werden kann, sollte sich der ISP an die Telefongesellschaft wenden. So funktioniert es hier, aber in Großbritannien kann es anders sein.

— SPRBRN

Ich meinte, man sollte so viele Punkte wie möglich parallel ausführen. In meinem Fall könnte mein ISP entscheiden, einen Techniker zu beauftragen, aber wenn das Problem so unbedeutend ist wie bei nicht verwendeten DSL-Filtern, wird möglicherweise eine Gebühr erhoben.

— Harrymc

Pfui. Die Kommentare beziehen sich auf Nummern in einer nummerierten Liste. Dann bearbeitete das Poster der Antwort die Antwort, um die Zahlen zu entfernen, wodurch die Kommentare fehl am Platz zu sein schienen. TSK tsk.

— TOOGAM

200 ms : Dies ist in die Windows / Linux-Software integriert. Ich fand es, als ich analysierte, warum das Produkt meines Unternehmens einen zu geringen TCP / IP-Durchsatz in kleinen Datagrammen aufwies, und fand dann die Systemaufrufe, die "sofort" senden, auf dem Socket. Packet Payload : Dies wird nicht ausgehandelt, vielmehr wird ein zu großes TCP / IP-Datagramm in Teile zerlegt, wenn es auf einen Pfad stößt, auf dem die MTU zu klein ist. DSL-Modem : Möglicherweise kompensiert eine Änderung der Parameter eine schlechte Telefonleitung / Vermittlung, sollte jedoch behoben und nicht kompensiert werden.

— Harrymc

Eine weitere Verbesserung: Deaktivieren Sie ADSL2 + und bleiben Sie für mehr Stabilität bei ADSL1. Welchen Router Sie auch kaufen, stellen Sie sicher, dass Sie die SNR-Ränder richtig einstellen können (einige Informationen hier ). Milliarden Router sind gut, genauso wie Netgear (ich bevorzuge die Modelle, die DD-WRT mit einfacher Installation unterstützen). Dieser Artikel kann Ihnen weitere Anregungen geben - und einen Blick auf das Strecken- / Geschwindigkeitsdiagramm werfen.

— Harrymc

Ich sehe diesen Fall sehr stark im Zusammenhang mit der Verwaltung von Datenstaus, obwohl es sich um einen sehr schlecht verwalteten Fall handelt, aus welchem Grund auch immer. Meines Erachtens ist der Paketpuffer entlang des Übertragungssystems schlecht verwaltet, was diese Anomalie in den ICMP-Echoanforderungs- / Antwortpaketen verursacht.

Die Kombination aus einer schlechten Überlastungsmanagementrichtlinie und einer stundenlangen Ping-Sitzung kann daher offensichtlich zu solch einem seltsamen Szenario führen.

Weitere Informationen zum Engpassmanagement finden Sie hier .

— Tamadite
quelle