Jak, u licha, ten zgłoszony godzinny czas pingowania może być prawdziwy?

Niedawno wielkanocne wakacje spędziłem z rodzicami, którzy mieszkają na bardzo wiejskim obszarze w Wielkiej Brytanii. Mają (okropne) połączenie z Internetem ADSL, które biegnie przez kilka kilometrów mglistej miedzi i jest okresowo przerywane, gdy pobliscy rolnicy odwracają ciągniki na linie telefoniczne.

Zauważyłem, że ich router wielokrotnie upuszczał pptp uścisk dłoni i renegocjował go, skutecznie zabijając połączenie. To było frustrujące. Tak więc, próbując uniknąć szaleństwa, powiedziałem, aby podwoić minimalny dopuszczalny margines SNR i uścisk dłoni dla niższych prędkości:

$ 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.

To się poprawiło, a rzecz stała się (nieco) stabilna, choć niesamowicie wolna, do świata zewnętrznego:

$ 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
...

Mniej więcej w tym momencie interweniowało prawdziwe życie, a następnie spędziłem kilka godzin, bawiąc się z kotami, patrząc na gify z kotów na moim telefonie, rozmawiając z rodziną itp. Zapomniałem, że zostawiłem ten proces ping uruchomiony i wróciłem dzień później trafić ctrl-c.

Pokazane statystyki podsumowujące mnie unosiły:

--- 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

Jak widać, maksymalny zarejestrowany czas odpowiedzi dla pakietu ICMP wykonującego krótki transatlantycki przeskok do serwera DNS Google wynosi 3600577,732 ms . To prawie dokładnie godzina , a na pewno znacznie dłużej niż pingdomyślny limit czasu.

Jak to może być na ziemi ? Jest to jest dokładne? Który router z radością utrzyma pakiet przez sześćdziesiąt minut, zanim wyśle go po drodze? Dlaczego ten pakiet nie został odrzucony? Czy jest to wynikiem przepełnienia 8-bitowego licznika pakietów w połączeniu z dużymi opóźnieniami?

Na koniec chciałbym wiedzieć, czy istnieje jakiś kodeks postępowania w Wielkiej Brytanii stwierdzający, że oczekuje się, że połączenia ADSL dla konsumentów będą miały mniejsze opóźnienia i lepsze zarządzanie ruchem niż w przypadku RFC 1149 i RFC 2549 ;-).

networking routing adsl

— Landak
źródło

router, który nie jest przeciążony spamem.

— maniak zapadkowy

Chciwy router;) Musisz po prostu w to zagrać, gdy zauważysz, że planuje czekać godzinę przed przesłaniem pakietu. youtube.com/watch?v=moSFlvxnbgk

— Cestarian

Czy to możliwe, że skoro powiedziałeś, że zostawiłeś go na noc, Twój komputer zastosował +1 godzinę na początku czasu letniego i to pomieszało się z obliczeniem RTT określonego pakietu?

— kenkh

@kenkh - Nie; Jestem pewien, że dzień, w którym zmieniły się zegary, nie był tym. Poza tym, patrząc na ping kod źródłowy (od ~ l 761) widzę, że strefy czasowe są ignorowane w późniejszych obliczeniach ( gettimeofday(nv, NULL)zwraca epokę mikrosekund). Naprawdę zajęło to godzinę!

— Landak,

jeśli masz dostęp do systemu, czy możesz uruchomić na nim ścieżkę? Z grubsza pokazywałby, gdzie jest spowolnienie

— Journeyman Geek

Odpowiedzi:

Pakiet ICMP i odpowiedź na ping mają długość 32 bajtów, więc wydaje się, że dla godzinnego pingowania przesyłanie każdego bajtu trwało prawie minutę.

Można to wytłumaczyć jedynie bardzo hojną liczbą ponownych prób błędów (co robisz?) W połączeniu z bardzo wolnym routerem i bolesnym oczekiwaniem lub ponawianiem prób dla każdego przesyłanego bajtu.

Protokół internetowy (IP) przesyła dane przez datagramy i stara się nie wysyłać częściowych. Po uruchomieniu transmisji będzie domyślnie czekał przez 200 milisekund, aby dodać więcej bajtów do datagramu. Po upływie tego czasu oprogramowanie / oprogramowanie wewnętrzne wyśle wszystko, co ma jako jeden datagram. W przypadku godzinnego pingowania ładunek pakietu mógł być tak mały jak jeden bajt. Dopóki dane wciąż docierają, połączenie nie zostanie zakończone przez dwie uczestniczące strony.

Co możesz zrobić :

Jeśli inne telefony, faksy lub inne urządzenia są podłączone do tej samej linii telefonicznej, sprawdź, czy są chronione przez filtry DSL . Upewnij się, że nie umieściłeś filtra w linii prowadzącej do modemu DSL.
Wypróbuj inny router - gdy masz już złe urządzenie, nic nie możesz na to poradzić poza wyrzuceniem go i zdobyciem czegoś lepszego.
Jeśli żaden inny router nie jest dostępny, skontaktuj się z usługodawcą internetowym - mogą przeprowadzić przydatne testy ze swojej strony.
Jeśli dostawca usług internetowych niczego nie znajdzie, spróbuj mimo to zażądać wymiany routera / modemu.
Jeśli ten sam problem występuje z innym routerem, skontaktuj się z firmą telekomunikacyjną.

Znalezienie problematycznego przełącznika może być dość skomplikowane, jak w przypadku firmy telekomunikacyjnej, ale dostawca usług internetowych może mieć także własne przełączniki. Zwykle problem z przełącznikiem dotyczy całego obszaru, co pomaga zlokalizować nieprawidłowo działający przełącznik. Ale na obszarach wiejskich, gdzie nie korzysta zbyt wielu abonentów, ten przełącznik może pozostać niewykryty. Jeśli niektórzy sąsiedzi korzystają z tego samego usługodawcy internetowego, spróbuj dowiedzieć się, jakie jest ich połączenie.

— harrymc
źródło

Odwróciłbym 2 i 3. O wiele łatwiej jest najpierw skontaktować się z dostawcą usług internetowych. Mogą zrobić test. Jeśli zauważą problemy, wyślą nowy modem (niekoniecznie router). Jeśli nowy modem nie rozwiąże problemu, dostawca usług internetowych powinien skontaktować się z firmą telefoniczną. Tak to działa tutaj, ale może być inaczej w Wielkiej Brytanii.

— SPRBRN

Miałem na myśli, że należy wykonać jak najwięcej punktów powyżej równolegle, jak to możliwe. W moim przypadku mój dostawca usług internetowych może zdecydować się na wysłanie technika, ale jeśli problem jest tak trywialny jak nieużywane filtry DSL, może zdecydować o naliczeniu opłaty.

— harrymc

Ugh. Komentarze odnoszą się do liczb na liście numerowanej. Następnie plakat odpowiedzi zredagował odpowiedź w celu usunięcia liczb, przez co komentarze wydawały się nie na miejscu. TSK TSK.

— TOOGAM

200 ms : Jest to wbudowane w oprogramowanie Windows / Linux. Znalazłem to, analizując, dlaczego produkt mojej firmy ma zbyt niską przepustowość TCP / IP na małych datagramach, a potem znalazłem wywołania systemowe, które „wysyłają natychmiast” do gniazda. Pakiet danych : To nie jest negocjowane, raczej zbyt duży datagram TCP / IP zostanie pocięty na części, gdy napotka ścieżkę, w której MTU jest zbyt mała. Modem DSL : możliwe, że zmiana parametrów nieco zrekompensuje złą linię telefoniczną / przełącznik, ale powinna zostać naprawiona, a nie skompensowana.

— harrymc

Kolejna poprawka: wyłącz ADSL2 + i pozostań z ADSL1 dla stabilności. Niezależnie od tego, który router kupisz, upewnij się, że możesz odpowiednio dostosować marginesy SNR (niektóre informacje tutaj ). Miliardy routerów są dobre, podobnie jak Netgear (wolę modele, które obsługują DD-WRT przy prostej instalacji). Ten artykuł może dać ci więcej pomysłów - i spójrz na diagram odległości / prędkości.

— harrymc

Widzę tę sprawę w bardzo dużym stopniu związaną z zarządzaniem ograniczeniami danych, chociaż bardzo źle zarządzaną z jakiegokolwiek powodu. O ile mi wiadomo, w systemie transmisji jest bufor pakietów - źle zarządzany, co powoduje tę anomalię w pakietach żądań / odpowiedzi echa ICMP.

Tak więc połączenie złej polityki zarządzania ograniczeniami z godzinną sesją ping może oczywiście doprowadzić do tak dziwnego scenariusza.

Więcej informacji na temat zarządzania ograniczeniami tutaj .

— Tamadyt
źródło