Najpierw cel, nie uniwersalna granica
W szybkich grach zwykle lepszy jest niski, stabilny czas w obie strony do faktycznego serwera gry. Poniższe zakresy to redakcyjne wskazówki do porównań, nie oficjalna norma ani gwarancja dla gry.
| Czas w obie strony | Orientacyjna interpretacja |
|---|---|
| Poniżej 50 ms | Cel niskiego opóźnienia dla szybkiej interakcji. |
| 50–100 ms | Gra może być możliwa; sprawdź tytuł i stabilność. |
| 100–150 ms | Opóźnienie może być bardziej zauważalne w szybkich grach. |
| Powyżej 150 ms | Często słabsza reakcja, ale nie dowód awarii. |
Nie traktuj tabeli jako wymagań wszystkich rozmów czy transmisji wideo. Rozmowy zależą też od jittera, strat i buforów, a buforowane wideo od przepustowości i stabilności. Pomiar przeglądarkowy nie gwarantuje wrażeń.
Ping, opóźnienie i stabilność
Zwykłe polecenie ping używa echa ICMP. RTT obejmuje drogę tam i z powrotem. Dzielenie go na pół nie daje wiarygodnego czasu w jedną stronę, bo trasy i kolejki mogą się różnić. Mbps oznacza pojemność łącza, nie opóźnienie w ms.
Zmienność często nazywa się jitterem; utrata pakietów jest osobną miarą. Zapisuj cel i metodę, bo narzędzia mogą liczyć różne statystyki.
Co faktycznie mierzy IPdidi
Test pingu wykonuje 2 żądania rozgrzewkowe i 40 pomiarów HTTP do /ping.txt w punkcie Cloudflare obsługującym witrynę. Nie wysyła ICMP i nie mierzy serwera gry.
Zwykle używa przedziału od requestStart do responseStart, który może obejmować przetwarzanie serwera. Gdy dane są niedostępne, mierzy czas fetch wraz z odczytem odpowiedzi. Nie gwarantuje czystego RTT sieciowego.
Wyświetlany jitter to średnia bezwzględna zmiana między sąsiednimi udanymi próbkami. Przekroczenie czasu lub błąd HTTP oznacza nieudaną próbkę, nie procent utraconych pakietów IP. Oceny zastosowań są heurystykami witryny. Opis wynika z kontroli kodu, nie z testu twojego łącza lub urządzenia.
Porównuj równe warunki
- Zapisz cel, narzędzie, porę, Wi-Fi lub kabel, VPN, średnią, zmienność i błędy.
- Powtórz bez obciążenia i podczas zwykłego pobierania lub wysyłania przy tym samym celu i metodzie.
- Porównaj Ethernet z Wi-Fi, jeśli możesz. Pomaga to wyodrębnić wpływ radia, ale nie gwarantuje niższego wyniku.
- Sprawdź diagnostykę gry lub aplikacji do rozmów. Dobry wynik do jednego punktu nie wyklucza problemów lokalnych, trasy, serwera czy aplikacji w innych sytuacjach.
Dla ICMP uruchom w terminalu ping example.com i zatrzymaj Ctrl+C, jeśli działa ciągle. Cel może filtrować echo; brak odpowiedzi nie dowodzi awarii usługi.
Jedna zmiana i kolejny pomiar
- Wstrzymaj duże transfery i kopie zapasowe, aby sprawdzić kolejki pod obciążeniem.
- Porównaj położenie i mniej zajęte pasma lub kanały Wi-Fi; 5 GHz nie zawsze wygrywa przez ściany lub na odległość.
- Porównaj odpowiedni region gry i VPN włączony/wyłączony podczas tej samej aktywności. VPN i szybszy plan nie gwarantują mniejszego opóźnienia.
- Jeśli router obsługuje zarządzanie kolejkami, stosuj dokumentację producenta. Może ono ograniczyć oczekiwanie, lecz nie odległość propagacji.
- Przy trwałym problemie podaj wsparciu cel, pory i wyniki bez obciążenia oraz z nim, nie tylko minimum.
Używaj tego samego testu przed i po zmianie. Różnica między dwoma celami nie wystarcza do diagnozy.
Częste pytania
Czy 100 ms zawsze jest złe?
Znaczenie zależy od zadania, celu, protokołu i stabilności. To pomiar do analizy, nie uniwersalny próg zaliczenia.
Czy błąd HTTP oznacza stratę pakietów?
Nie. Przyczyn może być wiele, a test nie określa sieciowej stopy strat.
Dlaczego gra pokazuje inną liczbę?
Cel, ruch i przetwarzanie są inne. Porównuj jej diagnostykę zamiast odejmować niepowiązane wartości.
Źródła i zakres
Opis dotyczy miar i sposobu porównania. Nie oznacza rozpoznania usterki twojego łącza ani testu konkretnego urządzenia.
Źródła sprawdzono: 2026-11-05.