Jak ten test mierzy twoje łącze
Ta strona dokładnie opisuje, co wysyła PingPacketTest.com, jak powstają z tego trzy liczby na stronie głównej i — w ostatniej części — czego te liczby nie mogą powiedzieć. Jeśli czytasz tylko jedną część, przeczytaj ostatnią.
Co naprawdę wysyła test
Przeglądarka otwiera DataChannel WebRTC do jednego z serwerów pomiarowych i wysyła małe pakiety. Kanał ma ustawione ordered: false i maxRetransmits: 0: przeglądarka nie może ani ponowić pakietu, ani wstrzymać go, bo brakuje poprzedniego. To prawdziwe UDP — ten sam transport, którego używa prawie każda gra online.
Każdy pakiet niesie numer i czas wysłania, dopełniony do rozmiaru pakietu wybranej gry. Serwer robi tylko jedno: odsyła go bez zmian. Czas w obie strony mierzy się więc w całości w twojej przeglądarce, jednym zegarem. Pakiet, którego echo nigdy nie wraca, liczy się jako utracony.
Dlaczego speedtest nie odpowie na to pytanie
Speedtest mierzy przepustowość przez TCP, które jest zbudowane tak, żeby ukryć właśnie ten problem: utracony pakiet zostaje po cichu wysłany ponownie, a na końcu zostaje trochę niższa prędkość.
Gra tak nie robi. Wysyła pozycję w stałym tempie i idzie dalej; utracona aktualizacja nigdy nie jest ponawiana. Dlatego łącze może zdać każdy speedtest, a mimo to dawać rubberbanding.
Tick rate: dlaczego wybrana gra zmienia pomiar
Serwer gry przesuwa świat w stałych krokach — tickach. To tempo decyduje, jak często pakiety idą przez twoje łącze i ile kosztuje dane opóźnienie: przy 128 tickach 60 ms w obie strony to prawie osiem aktualizacji, przy 20 tickach — ledwie jedna.
Wybór gry zmienia więc tempo wysyłania i rozmiar pakietu samego pomiaru. Tempo każdego tytułu, jego źródło i to, czy jest potwierdzone, czy szacowane, znajdziesz w bazie tick rate.
Gdzie stoją serwery pomiarowe
Są cztery: Nowy Jork, San Jose, Frankfurt i Singapur. Przeglądarka domyślnie mierzy do najbliższego; możesz przełączyć, żeby sprawdzić konkretną trasę. Serwer jest podany przy każdym wyniku, bo ping bez celu nic nie znaczy.
Jak powstają liczby
Pierwsza sekunda się nie liczy. Każdy pomiar zaczyna się od sekundy rozgrzewki: pakiety idą, ale nic nie jest liczone. Pierwsze pakiety na trasie są wolniejsze, a ten koszt należy do zestawienia połączenia, nie do twojego łącza. Dotyczy to tylko początku: przerwa w trakcie pomiaru pojawia się w całości.
Ping to mediana, z pełnym zakresem w tle. Wykres rysuje punkt co 100 ms; punkt to mediana pakietów z tego wycinka, a cieniowany pas sięga od najniższego do najwyższego. Nic nie jest wygładzane.
Utrata pakietów nigdy nie jest uśredniana. Jeden utracony pakiet rysuje swój znacznik na każdym poziomie przybliżenia. Pakiet uznany za utracony, który jednak dotrze, odzyskuje status: był spóźniony, nie zgubiony.
Jitter mierzy się w stałych oknach jednosekundowych (odchylenie standardowe czasów w obie strony w każdej sekundzie, uśrednione). Dzięki temu to samo łącze pokazuje ten sam jitter przy każdym tick rate. Czas powyżej 1000 ms liczy się jako utrata.
Jak powstaje werdykt i percentyl
Werdykt bierze najgorszą z trzech liczb, nie średnią. 20 ms pingu przy 2 % utraty to nie jest dobre łącze. Progi jittera wynikają z tick rate (pół ticku dla „dobrze”, cały tick dla „grywalnie”, z limitem 15 i 30 ms); progi pingu to ocena, podana tutaj: 30/60 ms od 100 Hz, 40/80 ms przy 60–64 tickach, 60/100 ms przy 30 tickach, 80/150 ms poniżej. Dla utraty próg jest wszędzie ten sam: powyżej 1 % to za mało.
Percentyl porównuje cię z pomiarami wykonanymi tutaj, nie z całym internetem. Osoby, które otwierają test utraty pakietów, nie są losową próbą — wiele przychodzi, bo coś już nie działa.
Co znaczy wiersz Typ NAT
W trakcie pomiaru wiersz stanu pokazuje typ pary kandydatów ICE, która naprawdę jest używana: host dla bezpośredniej publicznej drogi, server-reflexive dla przejścia przez NAT, który pozwolił na bezpośrednią trasę, relay dla połączenia przez pośrednika. Wyświetlane jako Otwarty, Umiarkowany i Ścisły — słowa z menu konsol. Przeglądarka nie odczyta wartości z konsoli; to jest równoważna obserwacja.
Jak liczone są przerwy i dostępność
Po minucie narzędzie mówi, co łącze robiło przez ten czas. Przerwa to odcinek co najmniej jednej pełnej sekundy, w którym w każdym oknie 100 ms zgubiono co najmniej jeden pakiet. Dostępność to część zmierzonego czasu poza takimi odcinkami. Wartości liczy się raz, na końcu, i zapisuje z wynikiem.
Czego ten test nie powie
Mierzymy trasę do naszego serwera, nie do serwera gry. Jeśli trasa do Frankfurtu jest czysta, a gra i tak się tnie, problem może leżeć między twoim dostawcą a centrum danych gry.
Pomiar w obie strony nie mówi, w którą stronę pakiet zginął. I to nie jest traceroute: pomiar dowodzi utraty na całej trasie, nie wskazując winnego odcinka.
Jeśli UDP jest zablokowane, test przechodzi na TCP. Ping dalej coś mówi, ale utrata wychodzi niższa niż w rzeczywistości, bo TCP ponawia pakiety. Tak samo przez przekaźnik (TURN): droga jest dłuższa niż twoja prawdziwa trasa.
Mierzymy łącze takie, jakie jest, ze wszystkim, co go używa. Pobieranie, aktualizująca się konsola albo stream w domu trafiają do wyniku. Jeśli pomiar wyjdzie źle, powtórz go ze wszystkim wyłączonym.
Przeglądarka nie jest środowiskiem czasu rzeczywistego. Mocno obciążony komputer albo karta w tle mogą dodać trochę jittera, który pochodzi z twojego urządzenia, nie od dostawcy.
To nie jest test prędkości. I nic na tej stronie nie jest losową próbą internetu: każde opublikowane porównanie mówi „spośród testów wykonanych tutaj”.
Co dalej
Baza tick rate wymienia każdą grę z wysyłanym tempem, źródłem i statusem. Statystyki utraty pakietów i statystyki na żywo są po angielsku. Test startuje, gdy tylko go otworzysz.
Pytania, poprawki albo błąd w metodzie: info@pingpackettest.com.