Speedtesty świetne, a w grach wysoki ping – diagnostyka SQM, bufferbloat, WinMTR, routery Asus, MikroTik, Ubiquiti

Pytanie

Internet na speed testach świetny lecz w grach bardzo wysoki ping

Odpowiedź Sztucznej Inteligencji

Bezpośrednia odpowiedź na pytanie

• Różnica wynika z tego, że speed testy mierzą głównie przepustowość i ping do najbliższego serwera, a gry potrzebują niskiego i stabilnego opóźnienia do konkretnych (często odległych) serwerów oraz odporności na obciążenie łącza.
• Najczęstsze przyczyny: bufferbloat (kolejkowanie w routerze), Wi‑Fi (zakłócenia/jitter), nieoptymalny routing ISP, przeciążenie sieci domowej, zmienność łączy komórkowych/kablowych w godzinach szczytu, problemy po stronie serwera gry.
• Szybkie działania: przejście na Ethernet, włączenie SQM/QoS w routerze, ograniczenie obciążenia upload/download do ~85–90% realnej przepustowości, test WinMTR/traceroute do serwera gry, aktualizacja firmware routera/sterowników NIC.

Szczegółowa analiza problemu

• Fundament: Speed test zestawia kilka dużych strumieni TCP do pobliskiego węzła i raportuje średnie. Gry wysyłają wiele małych pakietów (często UDP) o wysokiej częstotliwości, wrażliwych na opóźnienie, jitter i wahania kolejek.

• Gdzie zwykle „gubi się” ping:

  1. LAN (Twoje urządzenie i łącze do routera)
  • Wi‑Fi: CSMA/CA, retransmisje, ko‑kanałowe zakłócenia, „smart connect” i roaming powodują skoki pingu. Pasmo 2,4 GHz jest szczególnie podatne. 5 GHz/6 GHz jest lepsze, ale i tak gorsze od przewodu.
  • Ethernet: sporadycznie problemy z kablem (zagniecenia), złą autonegocjacją lub ustawieniami karty (EEE/Green Ethernet, Interrupt Moderation potrafią dodać kilkanaście ms pod obciążeniem).
  • System: tło (Windows Update/Delivery Optimization, chmury, launchery gier), DPC latency sterowników (np. ndis.sys, sterowniki audio/GPU) może powodować mikro‑freezy widoczne w grze jako „lag”, choć nie zawsze podnoszą ping ICMP.
  2. CPE/Router i ostatnia mila
  • Bufferbloat: przy nasyceniu uploadu (częste przy wideo/backupach/Discordzie) i/lub downloadu kolejki w routerze/modemie rosną; ping w grze skacze setkami ms mimo „świetnego” down/up w speedteście.
  • Rozwiązanie klasy inżynierskiej: SQM (Smart Queue Management) z FQ‑CoDel lub CAKE. Ustawienia: mierz realny up/down (nie katalogowy), wpisz ~85–90% tych wartości, włącz per‑host fairness; priorytetyzuj urządzenie gracza zamiast portów (gry używają dynamicznych portów).
  • Zwykły „QoS” oparty o klasy/priorytety bez kolejkowania sprawdza się słabiej niż SQM.
  3. Rdzeń i peering ISP (routing)
  • Nieoptymalne trasy, przeciążony peering lub tunelowanie (np. DS‑Lite/MAP‑T) zwiększają RTT/jitter do niektórych regionów. Wieczorne „peaki” to sygnał przeciążenia poza Twoim domem.
  • IPv4 vs IPv6: czasem IPv6 ma lepszą/ gorszą trasę. Warto porównać.
  4. Serwer gry i jego region
  • Odległość geograficzna i obciążenie instancji (tick rate, kolejki CPU serwera) wliczają się w „ping w grze”. Dwie różne instancje w tym samym regionie potrafią dać różny ping i jitter.
  5. Technologia dostępu
  • 5G/LTE i czasem sieci kablowe pod obciążeniem w rejonie mają wyraźną zmienność opóźnień. Światłowód bywa najstabilniejszy, ale nie eliminuje problemów z peeringiem.

• Diagnostyka krok‑po‑kroku (precyzyjnie, powtarzalnie):

  1. Ustal bazę na przewodzie
     • Podłącz PC kablem Cat5e/Cat6 bezpośrednio do routera. Zmierz:
       • ping do bramy domowej (Windows: ping -n 200 192.168.x.1) – oczekuj <1 ms, brak strat.
       • ping do publicznego węzła (1.1.1.1 i 8.8.8.8) – oczekuj stabilnych wartości; jitter ≤5–10 ms na stabilnym łączu.
  2. Test pod obciążeniem (bufferbloat)
     • W trakcie stałego uploadu (np. wysyłka pliku/chmura) ponów ping. Jeśli RTT rośnie o >20–30 ms lub skacze, masz problem z kolejkami. Włącz SQM na routerze; ustaw up/down na 85–90% REALNYCH wartości.
  3. Trasa do serwera gry
     • Użyj WinMTR (Windows) lub mtr (Linux/macOS) do IP serwera gry przez 5–10 minut.
       • Szukaj miejsca, od którego stabilnie rośnie średnia/worst; ignoruj pojedyncze wysokie czasy na węzłach z ograniczaniem ICMP, liczy się ostatni/końcowe.
       • Zapisz raporty z godzin „dobrych” i „złych” – to materiał dla ISP.
  4. Weryfikacja wpływu Wi‑Fi
     • Jeśli musisz bezprzewodowo: 5 GHz/6 GHz, kanał mniej zatłoczony, szerokość 40–80 MHz (nie zawsze 160 MHz!), wysoka moc nadawcza nie zawsze pomaga; unikaj urządzeń 2,4 GHz w tej samej sieci (airtime fairness).
  5. System i karta sieciowa
     • Aktualizacje sterowników NIC (Intel/Realtek z witryny producenta), firmware routera.
     • Ustawienia zaawansowane NIC (Ethernet): wyłącz EEE/Green Ethernet i ewentualnie Interrupt Moderation, jeśli obserwujesz skoki; zachowaj RSS i coalescing rozsądne (zbyt agresywne = większe opóźnienie).
     • W Windows wyłącz Delivery Optimization w czasie gry; w Resource Monitor (resmon.exe → Network) sprawdź, co faktycznie wysyła/odbiera.
  6. Serwer/region gry
     • Porównaj regiony; różnice rzędu 20–100 ms są normalne przez fizykę i trasę. Wybieraj najbliższe regiony i mniej obciążone instancje.
  7. Test VPN jako „sonda routingu”
     • Jednodniowy trial gaming‑VPN: jeśli ping/jitter istotnie spada, problemem jest trasa/peering ISP do konkretnego AS/regionu. Z raportami z WinMTR warto zgłosić to do ISP.

• Co NIE pomaga lub ma znikomy wpływ:

  • Zmiana DNS nie obniży pingu w grze (poza szybszym rozwiązaniem nazw przy starcie sesji).
  • „Przyspieszacze” TCP/MTU magiczne ustawki – poza poprawnym MTU (np. PPPoE 1492) nie oczekuj cudów.
  • „Tryby gaming” bez realnego SQM to marketing, jeśli nie ma FQ‑CoDel/CAKE.

Aktualne informacje i trendy

• W routerach klasy konsumenckiej coraz częściej pojawia się SQM (FQ‑CoDel/CAKE) i „traffic prioritization per‑device” – to realnie rozwiązuje bufferbloat w grach.
• Wi‑Fi 6/6E i nadchodzące 7 z MLO poprawiają stabilność opóźnień, ale przewód nadal wygrywa w grach czasu rzeczywistego.
• Coraz więcej platform gier/serwerów zapewnia wieloregionowy hosting; wybór instancji o mniejszym obciążeniu często daje większą korzyść niż zmiana ustawień graficznych.

Wspierające wyjaśnienia i detale

• Jitter (wariancja opóźnienia) jest równie groźny jak wysoki średni ping. To on daje „teleporty” i „hit‑reg” problemy mimo dobrego speedtestu.
• Upload nasycony jednym strumieniem (np. włączona kamera/stream, backup zdjęć) potrafi zepsuć grę bardziej niż download – gry intensywnie wysyłają dane stanów do serwera.
• W grach część „pingu” to także czas przetwarzania po stronie serwera; dlatego dwie instancje w tym samym mieście mogą dać różne wartości.

Aspekty etyczne i prawne

• VPN do gier bywa pomocny, ale sprawdź regulamin gry/antycheat (niektóre tytuły ograniczają VPN).
• Jeśli jesteś za CGNAT/DS‑Lite, może to wpływać na NAT/matchmaking. UPnP/port‑forwarding poprawia łączność, ale nie obniża samego RTT.

Praktyczne wskazówki

• Minimalny plan naprawczy (1 godzina):
  1. Gra na kablu Ethernet.
  2. Aktualizacja firmware routera i sterowników NIC.
  3. Włączenie SQM (FQ‑CoDel/CAKE) i ustawienie up/down na 85–90% realnej przepustowości.
  4. Zamknięcie chmur/aktualizacji/streamów podczas gry.
  5. WinMTR 10 min do serwera gry w „złych” godzinach – archiwizacja wyników.
• Dla Wi‑Fi (gdy przewód niemożliwy): 5 GHz/6 GHz, własny kanał, sensowna szerokość pasma (często 40–80 MHz), włącz „airtime fairness”, wyłącz „band steering”, jeśli powoduje przełączanie w trakcie gry.

Ewentualne zastrzeżenia lub uwagi dodatkowe

• Jeśli problem występuje tylko w jednej grze lub konkretnym regionie – to może być wyłącznie kwestia tamtejszych serwerów/routingu i poza Twoją kontrolą.
• Sieci komórkowe (LTE/5G) potrafią mieć świetny speedtest i jednocześnie zmienny ping w grach z powodu harmonogramowania radiowego i przeciążenia komórki.

Sugestie dalszych badań

• Sprawdź „bufferbloat test” (narzędzia specjalistyczne online) oraz Flent/NetPerf/iperf3 do pomiarów pod obciążeniem.
• Zapoznaj się z dokumentacją SQM (CAKE/FQ‑CoDel) dla Twojego modelu routera (OpenWrt/Ubiquiti/MikroTik/AsusWRT‑Merlin).
• Monitoruj ping/jitter w czasie (skrypty ping + wykresy RRD/Prometheus) – koreluj z godzinami i obciążeniem domowym.

Krótkie podsumowanie

• „Świetny speedtest” nie gwarantuje niskiego pingu w grach. Najczęściej winny jest bufferbloat lub Wi‑Fi. Najskuteczniejsze działania to: granie po Ethernet, włączenie SQM (FQ‑CoDel/CAKE) z limitem 85–90% realnego up/down, ograniczenie uploadu w tle, oraz diagnoza trasy WinMTR do docelowego serwera gry. Jeśli VPN znacząco poprawia wyniki – problem leży w routingu/peeringu ISP.

Na koniec proszę o kilka danych, abym mógł zaproponować ustawienia „pod klucz”:

• Jaka technologia łącza (światłowód/kablowe/DSL/5G‑LTE), nominalny i realny up/down?
• Model routera i czy masz dostęp do SQM/FQ‑CoDel/CAKE?
• Połączenie przewodowe czy Wi‑Fi (jeśli Wi‑Fi: pasmo, kanał, odległość, liczba sąsiednich sieci)?
• W jakich grach/regionach i o jakich porach występuje problem? Jaki jest typowy ping/jitter/packet loss w grze?
• Wynik 10‑min WinMTR do IP serwera gry (średni/worst, od którego hopa rośnie).