Jitter i utrata pakietów – jak znaleźć przyczynę zrywania rozmów, gier i transmisji

Kobieta przy laptopie diagnozująca domową sieć z routerem i przewodem Ethernet.

Rozmowa na Teams nagle się urywa, przeciwnik w grze przeskakuje po ekranie, a transmisja na żywo co kilkanaście sekund gubi obraz. Tymczasem test prędkości pokazuje 600 Mb/s pobierania i 100 Mb/s wysyłania. To nie musi być sprzeczność. Wolny internet oznacza przede wszystkim ograniczoną przepustowość, natomiast niestabilne połączenie to problem z terminowym i niezawodnym dostarczaniem danych. Nawet szybkie łącze światłowodowe może mieć chwilowe skoki opóźnień i utratę pakietów.

Przeglądarka potrafi ponowić pobieranie brakujących danych, ale rozmowa głosowa czy gra sieciowa nie może bez końca czekać na opóźnione informacje. Dlatego przy diagnozowaniu takich problemów ważniejsze od maksymalnej prędkości bywają jitter, packet loss i opóźnienie pod obciążeniem. Ich pomiar pozwala ustalić, czy należy poprawić domowe Wi-Fi, konfigurację routera, czy zgłosić problem operatorowi.

Czym są jitter, packet loss i chwilowe skoki opóźnień

Ping, czyli potoczna nazwa opóźnienia sieciowego, zwykle odnosi się do RTT (Round-Trip Time). Jest to czas potrzebny na przesłanie pakietu do wskazanego urządzenia i odebranie odpowiedzi. Wynik 20 ms oznacza, że cała taka podróż trwała 20 milisekund. Nie jest to czas przesyłania danych wyłącznie w jednym kierunku.

Dla gracza 20 ms to zazwyczaj dobry wynik, ale średnia nie pokazuje wszystkiego. Połączenie, w którym kolejne odpowiedzi przychodzą po 18, 21, 19, 240 i 20 ms, zachowuje się inaczej niż takie, które stale utrzymuje 25 ms. Ten pojedynczy skok do 240 ms może wystarczyć, żeby postać w grze na moment przestała reagować.

Jitter opisuje zmienność opóźnienia dostarczania pakietów. W komunikacji głosowej wykorzystującej RTP jest wyznaczany na podstawie różnic w czasie nadejścia kolejnych pakietów względem ich czasu wysłania. Nie należy utożsamiać go z różnicą między największym a najmniejszym pingiem ani z wartością mdev, którą pokazuje linuksowy ping. mdev opisuje odchylenie czasów RTT i jest przydatne w diagnostyce, ale nie stanowi pomiaru jittera RTP.

Trzeci parametr to packet loss, czyli utrata pakietów. Gdy urządzenie wysyła 1000 pakietów, a 20 nie dociera do odbiorcy, strata wynosi 2%. Przy pobieraniu pliku TCP może ponownie przesłać brakujące dane. W rozmowie prowadzonej na żywo retransmisja często docierałaby zbyt późno. Aplikacja próbuje wtedy odtworzyć brakujący dźwięk albo pomija fragment informacji.

W praktyce do wstępnej oceny połączenia czasu rzeczywistego można przyjąć następujące orientacyjne wartości:

  • RTT poniżej 30 ms do konkretnego serwera – bardzo dobry wynik dla większości gier i rozmów, choć wymagania zależą od aplikacji oraz lokalizacji serwera.
  • RTT 30–60 ms – zwykle komfortowe warunki, szczególnie gdy opóźnienie jest stabilne.
  • RTT powyżej 100–150 ms – opóźnienie może stać się odczuwalne w dynamicznych grach i rozmowach.
  • Jitter poniżej 10–20 ms – zazwyczaj korzystny dla głosu; znaczenie wyniku zależy od sposobu jego pomiaru i bufora aplikacji.
  • Strata pakietów 0% – pożądany wynik, ale nawet długi test z zerową stratą nie gwarantuje braku problemów w przyszłości.
  • Powtarzająca się strata 1–2% lub większa – istotny sygnał ostrzegawczy przy grach i komunikacji głosowej, szczególnie jeśli występuje seriami.

To wartości pomocnicze, a nie sztywne normy jakości internetu. Znaczenie ma również długość pomiaru. Jeden utracony pakiet na 100 prób oznacza 1%, lecz nie mówi, czy problem jest stały, czy zdarzył się przypadkowo.

Ważny jest także bufferbloat, czyli nadmierny wzrost opóźnienia spowodowany gromadzeniem pakietów w kolejkach urządzeń sieciowych. Typowy przykład: światłowód działa bez zarzutu, dopóki ktoś nie zacznie wysyłać dużego archiwum do chmury. Wtedy ping rośnie z 15 do 250 ms, mimo że test przepustowości nadal wygląda dobrze.

Przyczyną bywa zapchany upload. Router zamiast szybko obsłużyć niewielkie pakiety rozmowy, ustawia je za dużą kolejką innych danych. W takiej sytuacji sens ma ograniczenie transferów w tle lub konfiguracja SQM (Smart Queue Management), przykładowo z mechanizmem CAKE albo FQ-CoDel, jeżeli router je obsługuje. Trzeba jednak uwzględnić ograniczenia sprzętowe: zaawansowane zarządzanie kolejkami potrafi obciążyć procesor routera i zmniejszyć maksymalną przepustowość. Gdy opóźnienia występują również przy całkowicie nieobciążonym łączu, samo SQM nie usunie ich przyczyny.

Jak diagnozować połączenie za pomocą ping, MTR i traceroute

Diagnostykę najlepiej rozpocząć od najprostszego narzędzia, czyli ping. Nie potrzeba płatnego oprogramowania ani dostępu do panelu administracyjnego operatora.

Najpierw należy ustalić adres bramy domyślnej, zazwyczaj routera obsługującego sieć lokalną. Nie należy z góry wpisywać 192.168.1.1, ponieważ router może korzystać z innej adresacji.

W Windows otwórz Wiersz polecenia i wpisz:

ipconfig

Znajdź aktywną kartę Ethernet lub Wi-Fi i odczytaj pole „Brama domyślna”. W Linuksie można użyć:

ip route

Wynik zawierający default via wskaże bramę dla danej trasy IPv4. W macOS odpowiednim poleceniem jest:

route -n get default

Odczytany adres IPv4 bramy podstaw następnie do testu ping.

Windows:

ping -n 100 ADRES_BRAMY

ping -n 100 1.1.1.1

Linux i macOS:

ping -c 100 ADRES_BRAMY

ping -c 100 1.1.1.1

Adres 1.1.1.1 jest publicznym adresem usługi Cloudflare. Sto zapytań wysyłanych standardowo mniej więcej co sekundę daje około 100 sekund obserwacji. Na Windows można też uruchomić ping -t 1.1.1.1 i zakończyć pomiar skrótem Ctrl+C.

Co właściwie mówi taki test?

Jeżeli komputer podłączony kablem Ethernet uzyskuje do bramy odpowiedzi na poziomie 1 ms, bez utraconych pakietów, ale do publicznego adresu obserwuje okresowe opóźnienia 300 ms, podejrzenie przesuwa się poza lokalne połączenie komputer–router. Nie dowodzi to jeszcze winy dostawcy. Problem może dotyczyć routera podczas obsługi ruchu internetowego, dostępu operatora, trasowania albo sposobu odpowiadania serwera na ICMP.

Warto więc przeprowadzić pomiar według uporządkowanej procedury:

  1. W spoczynku: wyłącz intensywne pobieranie, synchronizację chmury i transmisje w tle. Sprawdź bramę oraz dwa niezależne cele, np. 1.1.1.1 i 8.8.8.8.
  2. Pod obciążeniem: powtórz testy podczas dużego pobierania, a następnie podczas wysyłania pliku. Sprawdź, czy znacząco rośnie RTT albo pojawiają się straty.
  3. W chwili awarii: prowadź pomiar równolegle z rozmową lub grą. Zapisz godzinę zakłócenia i porównaj ją z wynikami.
  4. Na drugim urządzeniu: powtórz eksperyment, zachowując możliwie identyczne warunki. To pomaga oddzielić problem komputera od problemu całej sieci.

Nie uruchamiaj wielu testów pełnej przepustowości jednocześnie, jeśli chcesz ocenić zachowanie połączenia w spoczynku. Sam pomiar prędkości silnie obciąża łącze i może zmienić obserwowane opóźnienia.

Kolejny etap to traceroute, który pokazuje urządzenia pośredniczące w trasie do celu. W Windows służy do tego:

tracert -d 1.1.1.1

W Linuksie i macOS:

traceroute -n 1.1.1.1

Opcje -d i -n w tych przykładach wyłączają rozwiązywanie nazw urządzeń, dzięki czemu wynik jest czytelniejszy. Narzędzie traceroute może wymagać instalacji w niektórych dystrybucjach Linuksa.

Traceroute pozwala sprawdzić przebieg trasy, ale nie jest wiarygodnym pomiarem długotrwałej stabilności. W tym celu bardziej użyteczny bywa MTR, który łączy obserwację kolejnych przeskoków z powtarzanymi pomiarami.

Przykładowe polecenie dla Linuksa lub macOS po zainstalowaniu MTR:

mtr -n -r -c 100 1.1.1.1

Parametr -n wyłącza rozwiązywanie nazw, -r generuje raport końcowy, a -c 100 ustawia 100 cykli pomiarowych. W systemie Windows podobne informacje można uzyskać za pomocą WinMTR lub wbudowanego pathping, choć programy te nie działają identycznie.

Raport MTR zawiera między innymi procent strat (Loss%), liczbę wysłanych prób (Snt) oraz czasy odpowiedzi. Najważniejsza zasada interpretacji brzmi: utrata pakietów na pośrednim przeskoku nie oznacza automatycznie awarii tego urządzenia ani łącza za nim.

Przykład: trzeci router na trasie pokazuje 60% strat, następny 0%, a adres końcowy również 0%. Takie zachowanie często wynika z ograniczania częstotliwości odpowiedzi ICMP (ICMP rate limiting) albo niskiego priorytetu obsługi pakietów diagnostycznych. Router może przekazywać właściwy ruch poprawnie, mimo że sam odpowiada na niewielką część zapytań.

Inaczej wygląda sytuacja, gdy straty pojawiają się od określonego miejsca i utrzymują również na kolejnych przeskokach oraz na docelowym serwerze. Jest to mocniejsza przesłanka problemu z transmisją, choć nadal należy brać pod uwagę różnice w trasach i reakcjach na pakiety testowe.

MTR i ping badają określony rodzaj ruchu. Gra może korzystać z UDP, a test z ICMP. Dlatego dobrym uzupełnieniem są statystyki samej aplikacji, jeżeli pokazuje ona opóźnienie, utracone pakiety albo jitter odbieranego strumienia.

Najgorsza decyzja to wysłanie operatorowi zrzutu z pojedynczego traceroute i stwierdzenie, że „trzeci serwer gubi pakiety”. Dużo bardziej przekonujące są powtarzalne wyniki z różnych godzin, kilku celów i połączenia kablowego, zestawione z rzeczywistymi momentami awarii.

Jak odróżnić problem operatora, routera, Wi-Fi i urządzenia

Pierwszy podział powinien dotyczyć miejsca występowania usterki: czy zakłócenie zaczyna się jeszcze w domu, czy dopiero w drodze do internetu. Najbardziej przydatnym testem jest porównanie Wi-Fi z przewodowym Ethernetem. Kabel nie jest automatycznym lekarstwem na każde zerwanie połączenia, ale usuwa z eksperymentu zakłócenia radiowe.

Załóżmy, że laptop podczas rozmowy wideo ma skoki RTT do bramy wynoszące 150–400 ms. Po podłączeniu przewodu uzyskuje stabilne 1 ms do routera, a rozmowa przestaje się rwać. Taki wynik mocno wskazuje na problem z łącznością bezprzewodową.

Najczęściej sprawdzają się wtedy następujące działania:

  • Pasmo 5 GHz lub 6 GHz: ma sens dla urządzeń znajdujących się stosunkowo blisko punktu dostępowego. Zwykle oferuje lepsze warunki pracy w zatłoczonych sieciach niż 2,4 GHz, ale słabiej przenika przez przeszkody. Pasmo 6 GHz wymaga zgodnego sprzętu i dostępności tej funkcji.
  • Pasmo 2,4 GHz: bywa korzystniejsze na większą odległość, choć jest bardziej narażone na zakłócenia powodowane przez sąsiednie sieci i inne urządzenia.
  • Zmiana kanału i szerokości kanału: w zatłoczonym bloku kanał 80 MHz nie zawsze będzie lepszy niż 40 MHz. Szerszy kanał zwiększa możliwą przepustowość, ale zajmuje więcej widma i może częściej kolidować z innymi sieciami.
  • Zmiana położenia routera: ustawienie go poza metalową szafką, dalej od dużych przeszkód i bliżej stanowiska pracy potrafi usunąć problem bez kupowania nowego sprzętu.

Jeśli jednak straty występują również na kablu, nie ma sensu zaczynać od zmiany kanałów Wi-Fi. Trzeba sprawdzić router, urządzenie końcowe i połączenie operatora.

Router może być wąskim gardłem, szczególnie podczas dużego uploadu, aktywnego VPN, filtrowania ruchu albo obsługi wielu urządzeń. Jeśli problemy występują tylko pod obciążeniem, należy obserwować wykorzystanie procesora routera, jego statystyki interfejsów i przyrost opóźnienia.

Dobrym testem jest ograniczenie transferu w tle, a następnie porównanie wyników. Gdy upload łącza wynosi 30 Mb/s, ustawienie limitu przykładowo na 25 Mb/s może pomóc ustalić, czy kolejki odpowiadają za opóźnienia. Nie jest to uniwersalna wartość optymalna – rzeczywista przepustowość, narzut protokołów i działanie routera wpływają na efekt.

Przy problemie konkretnego komputera objawy wyglądają inaczej. Jeśli dwa urządzenia pracują stabilnie, a tylko jeden laptop traci pakiety, priorytetem staje się aktualizacja sterownika karty sieciowej, sprawdzenie trybów oszczędzania energii, obciążenia CPU, programów VPN i filtrów bezpieczeństwa.

Przykładowo laptop z kartą Wi-Fi przechodzącą w agresywny tryb oszczędzania energii może okresowo opóźniać odbieranie danych. Zmiana ustawienia zasilania lub aktualizacja sterownika ma wtedy większy sens niż wymiana routera. Jeżeli zakłócenia występują wyłącznie w jednej aplikacji, trzeba dodatkowo sprawdzić jej serwer, statystyki połączenia i obciążenie samego programu.

Kiedy podejrzewać operatora? Przede wszystkim wtedy, gdy problem utrzymuje się na kilku urządzeniach, również podłączonych przewodowo, przy niewielkim obciążeniu sieci. Jeżeli router nie wykazuje błędów lokalnych, a straty do różnych zewnętrznych celów powtarzają się w określonych godzinach, zgłoszenie dostawcy staje się uzasadnione.

W polskich warunkach warto też rozróżnić technologię dostępu. Na łączu światłowodowym FTTH problem może dotyczyć urządzenia ONT, routera, sieci operatora lub dalszego trasowania. W internecie kablowym znaczenie mogą mieć parametry sygnału i obciążenie segmentu dostępowego. W LTE i 5G dodatkowo dochodzą poziom sygnału, zakłócenia radiowe, obciążenie stacji bazowej i przełączanie pasm.

Jeżeli internet mobilny wieczorami uzyskuje RTT rzędu 200 ms, a rano 30 ms, możliwe jest przeciążenie sieci radiowej. Samo porównanie dwóch pomiarów nie rozstrzyga jednak przyczyny. Należy sprawdzić parametry połączenia radiowego i wykonać serię testów o podobnych porach.

Przed zgłoszeniem do operatora przygotuj krótką dokumentację: daty i godziny zerwań, informację o połączeniu kablowym, wyniki ping do kilku celów, raport MTR oraz porównanie testu w spoczynku i pod obciążeniem. Sprawdź także dziennik zdarzeń routera i, jeśli urządzenie udostępnia takie dane, stan interfejsu WAN.

Nie ma natomiast sensu wymieniać routera za kilkaset złotych wyłącznie dlatego, że jeden test MTR pokazał stratę na urządzeniu pośrednim. Podobnie przejście z pakietu 300 Mb/s na 1 Gb/s nie rozwiąże automatycznie problemów z jitterem. Większa przepustowość nie oznacza gwarancji niższych opóźnień.

FAQ – najczęstsze pytania o jitter i utratę pakietów

Czy 1% packet loss to dużo?
W połączeniach czasu rzeczywistego powtarzająca się strata 1% może być odczuwalna, szczególnie gdy pakiety giną seriami. Przy pobieraniu plików jej skutki są zwykle mniej widoczne, ponieważ protokoły transmisji mogą ponawiać przesyłanie danych.

Jaki jitter jest dobry do gier online?
Niska i stabilna zmienność opóźnienia jest korzystniejsza niż częste skoki. Orientacyjnie jitter poniżej 10–20 ms wygląda dobrze, ale wyniki różnych narzędzi nie zawsze są porównywalne. Istotne są również RTT i rzeczywiste straty do serwera gry.

Czy ping 10 ms gwarantuje brak lagów?
Nie. Ping pokazuje RTT w konkretnym pomiarze. Połączenie może mieć średnio 10 ms, a co kilkanaście sekund notować skok do 300 ms albo gubić pakiety.

Czy zmiana DNS naprawi packet loss?
Zwykle nie. DNS odpowiada głównie za tłumaczenie nazw domen na adresy IP. Zmiana serwera DNS może pomóc przy problemach z rozpoznawaniem nazw, ale nie naprawia fizycznych zakłóceń Wi-Fi ani przeciążonego łącza.

Czy VPN może poprawić stabilność połączenia?
Czasem tak, jeżeli zmienia trasę omijającą problematyczny fragment sieci. Zwykle jednak dodaje narzut i może zwiększyć opóźnienie. VPN należy traktować jako test alternatywnej trasy, a nie podstawową metodę usuwania utraty pakietów.

Kiedy zgłosić problem operatorowi?
Gdy straty lub duże skoki opóźnień powtarzają się na połączeniu kablowym, do kilku niezależnych celów, także przy nieobciążonej sieci. Najlepiej dołączyć wyniki z różnych godzin oraz wskazać, kiedy zakłócenia występują w rzeczywistych aplikacjach.

Od czego zacząć diagnozowanie zrywających się rozmów i gier?
Najpierw podłącz komputer bezpośrednio przewodem Ethernet do routera, wyłącz intensywne transfery i wykonaj po 100 prób ping do ustalonej bramy oraz dwóch publicznych adresów, np. 1.1.1.1 i 8.8.8.8. Następnie powtórz pomiar pod obciążeniem. Jeśli problem znika na kablu, zajmij się Wi-Fi. Jeśli pozostaje, porównaj drugie urządzenie i zbierz raport MTR, zanim wymienisz sprzęt lub złożysz reklamację.

Leave a reply

Your email address will not be published. Required fields are marked *

Ciasteczka

Kontynuując przeglądanie strony, wyrażasz zgodę na używanie plików Cookies. Więcej informacji znajdziesz w polityce prywatności.