Latence, jitter a packet loss ve hrách

Všemu, co se na síti špatně hraje, se říká lag, a proto se tolik času tráví opravováním špatné věci. Jsou to tři různá měření s různými příčinami a minuta ping ti řekne, které z nich máš.

Latence je doba, kterou trvá cesta tam a zpět, a z velké části ji určuje vzdálenost. Jitter je to, jak moc tato doba kolísá, a obvykle za ním stojí něčí vlastní připojení. Packet loss jsou zprávy, které nikdy nedorazí, a obvykle za ním stojí jeden konkrétní hop. Čtvrtá věc se také nazývá lag a se sítí nemá nic společného: server, kterému došel CPU a nestíhá vlastní ticky. Rozlišit těchto čtyř věcí je celé umění a zbytek článku je o tom, jak na to.

Tři čísla a jak se každé z nich projevuje#

Latence má podlahu danou fyzikou a strop daný vybavením. Světlo v optickém vlákně urazí zhruba 200 km za milisekundu a paket musí jít oběma směry, takže každých 1 000 km trasy stojí asi 10 ms zpátečního času, než se čehokoli dotkne cokoli jiného. Skutečné trasy nikdy nejsou přímé a každý router, každý optický zesilovač a každý přetížený spoj k tomu něco přidá.

Jitter je to, co hry skutečně ničí. Herní klient je predikční stroj: odhaduje, kde bude všechno stát, a opraví se, když mu server řekne něco jiného. Okolo stálého zpoždění se predikuje snadno. Zpoždění, které kolísá mezi 30 a 140 ms, ne, a právě ty opravy hráči cítí jako rubber-banding a špatně načasované zásahy. Pod 5 ms je výborné, pod 15 ms v pořádku, nad 30 ms je zážitek rozbitý, ať říká průměr cokoli.

Packet loss je u každého paketu binární a v souhrnu statistický. Pod 0,1 % si ho nikdo nevšimne. Mezi 0,5 % a 2 % se střílečka chová špatně a survival hra většinou ne. Nad 2 % je špatné všechno. Důležitější než číslo je rozložení: 2 % rovnoměrně rozložených se dá přežít, ale 2 % přicházejících jako série čtyřiceti po sobě jdoucích ztracených paketů jednou za minutu je odpojení s přidanými kroky.

Stálých 90 ms se hraje líp než kolísavých 40. Ve hře předvídatelnost poráží rychlost.

Kam se milisekundy doopravdy ztrácejí#

Číslo v rohu obrazovky není celé zpoždění mezi stiskem klávesy a viditelným výsledkem. Když znáš zbytek rozpočtu, přestaneš honit 10 ms sítě, zatímco 80 ms leží někde jinde.

Dvě z těchto fází stojí za to pořádně pochopit.

Tick. Server zpracovává svět v diskrétních krocích. Tvůj vstup dorazí někdy během kroku a zpracuje se až v dalším, takže server běžící na 20 ticků za sekundu přidá až 50 ms a v průměru 25. Při 64 tickech za sekundu je to nejvýš 15,6 ms. Proto se tick rate vůbec uvádí a proto jeho zvýšení stojí CPU, ne šířku pásma - celý kompromis najdeš v článku what tick rate actually means.

Interpolační buffer. Klienti záměrně vykreslují svět mírně v minulosti, aby pozdní paket nevytvořil viditelnou mezeru. U starších her na enginu Source to bylo explicitní a nastavitelné: cl_interp_ratio 2 při cl_updaterate 66 bufferuje dvě aktualizace, což je asi 30 ms záměrného zpoždění. Novější hry to nastavují za tebe a ovládací prvky většinou nezpřístupňují. Právě kvůli bufferu může hra působit plynule při 100 ms a hrozně při kolísavých 40: buffer pohltí stálé zpoždění, ale ne rozptyl.

Jak je rozlišit za šedesát vteřin#

Jeden příkaz. Spusť ho na sto paketů, ne na pět.

$ ping -c 100 -i 0.2 play.example.com--- play.example.com ping statistics ---100 packets transmitted, 100 received, 0% packet loss, time 19871msrtt min/avg/max/mdev = 41.2/43.8/58.1/2.4 ms

Souhrnný řádek odpovídá na všechny tři otázky:

• 0% packet loss a nízké mdev při vysokém avg: čistá latence. Server je daleko nebo je špatná trasa. Na serveru to nic neopraví.
• Nízké avg a max několikanásobně vyšší než min, s mdev nad zhruba 10: jitter. Podívej se nejdřív na vlastní připojení klienta.
• Cokoli nad 0 % ztrát, trvale: packet loss. Najdi hop.
• Všechna tři čísla v pořádku, a přesto se hra hraje špatně: není to síť. Přeskoč na část o serveru.

mdev je střední odchylka, což je jako náhrada za jitter dost dobré. Windows ji nevypisuje, takže použij rozptyl mezi Minimum a Maximum:

ping -n 100 play.example.com

Dvě výhrady k ping, které záleží. Používá ICMP, kdežto hra používá TCP nebo UDP na konkrétním portu, takže firewall nebo omezovač rychlosti s nimi může zacházet jinak - skutečnou věc otestuje mtr --tcp --port 25565 nebo --udp. A ping na adresu serveru testuje cestu, ne hru: server přetížený na 100 % CPU odpovídá na pingy okamžitě, zatímco jeho svět běží poloviční rychlostí.

Jak číst report z mtr, aby tě nenachytal#

mtr pinguje každý hop na trase a je to nejužitečnější nástroj z tohoto článku, a zároveň nejčastěji špatně čtený.

$ mtr -rwzbc 200 play.example.comHOST                                 Loss%  Snt  Last   Avg  Best  Wrst StDev 1. AS???    192.168.1.1               0.0%  200   0.6   0.7   0.5   2.1   0.2 2. AS12345  10.0.0.1                  0.0%  200   8.1   8.6   7.9  18.4   1.1 3. AS12345  core1.isp.example        14.0%  200  11.2  11.9  10.8  29.1   2.0 4. AS3356   ae-1.fra.example.net       0.0%  200  38.4  38.9  38.1  44.2   0.8 5. AS64500  play.example.com           0.0%  200  41.0  41.6  40.9  48.7   1.2

Tento report ukazuje zdravou trasu. Těch 14 % na hopu 3 není ztráta a číst je jako ztrátu je klasická chyba.

• Ztráta na mezilehlém hopu, která nepokračuje až do konce, není skutečná. Routery snižují prioritu ICMP mířícího na ně samotné, zatímco provoz přeposílají bezchybně. Ztráta, kterou tvůj provoz opravdu trpí, je jen ta, která se objeví na nějakém hopu a přetrvá na každém dalším.
• Rozhoduje poslední řádek. Pokud poslední hop ukazuje 0 % ztrát, tvoje trasa žádné ztráty nemá, ať vypadá střed reportu jakkoli.
• Skok latence na jednom hopu je normální - to je dálkový spoj. Skok, který se na každém dalším hopu dál zvětšuje, je zahlcení.
• Zpáteční cesta je neviditelná. mtr ukazuje jen směr tam a internetové trasy jsou často asymetrické. Pokud report vypadá čistě a problém je skutečný, spusť mtr i ze serveru zpět k hráči. Právě tam se špatný hop často skrývá.
• Spouštěj ho za problému. Čistý report ve 3 odpoledne nedokazuje nic o večeru, který se rozpadne ve 20:00, a přesně to je podpis přetíženého peeringového spoje.

Podrobněji o výkladu reportu je Reading traceroute and mtr a na Windows tutéž práci dělá WinMTR.

Jitter: bufferbloat, wifi a fronta v tvém vlastním domě#

Většina jitteru vzniká do dvaceti metrů od hráče.

Bufferbloat je ten největší a skoro nikdo ho nekontroluje. Domácí routery drží velkou frontu paketů čekajících na odeslání. Když někdo nahrává video nebo se na pozadí aktualizuje hra, fronta se naplní a každý další paket čeká za frontou, která může obsahovat několik set milisekund provozu. Ping skočí ze 40 ms na 400 ms, dokud je linka vytížená, a vrátí se, hned jak je volná.

Otestuj to za třicet vteřin: spusť souvislý ping, pak spusť velký upload a sleduj čísla. Pokud se ztrojnásobí, je to bufferbloat. Řešením je chytré řízení front - fq_codel nebo cake - na routeru, s shaperem nastaveným zhruba na 85-90 % naměřené rychlosti linky, aby fronta vznikala ve vybavení, které ovládáš ty, a ne u poskytovatele. OpenWrt to nabízí jako SQM a několik spotřebitelských routerů tomu říká Smart Queue.

Wifi je druhá polovina. Znovu odeslaný rámec dorazí pozdě, ne nikdy, takže wifi vytváří jitter, ne ztráty. 2,4 GHz sdílí spektrum se všemi sousedy a většinou mikrovlnek, 5 GHz může beze varování změnit kanál, když zjistí radar, a mesh systémy, které používají jedno rádio pro klienty i pro backhaul, snižují vysílací čas na polovinu. Kabel tohle všechno odstraní a je to nejcennější věc, kterou může stěžující si hráč udělat. Powerline adaptéry jsou co do nepředvídatelnosti rovnocenné wifi a je třeba s nimi zacházet stejně.

VPN má smysl vyzkoušet, když důkazy ukazují na špatnou trasu u poskytovatele, protože může tvůj provoz přesunout na jinou cestu. Stejně dobře ale může přidat přetížený hop. Než se rozhodneš, změř s ní i bez ní, ve stejný večer.

Packet loss: co dělá s TCP a s UDP#

Příznak úplně závisí na protokolu, a proto stejné 2 % ztrát vyvolají dvě naprosto odlišné stížnosti.

Hry na TCP zamrznou a dožene se to. TCP zaručuje doručení i pořadí, takže ztracený paket zastaví všechno za sebou, dokud nedorazí opakované odeslání, což stojí alespoň jednu cestu tam a zpět. Minecraft Java běží na TCP, a proto se ztráty projeví půlsekundovým zaseknutím, po kterém se všechno stane najednou, a ne teleportováním.

Hry na UDP přeskakují. UDP nic znovu neposílá, takže hra tu aktualizaci stavu prostě nikdy nedostane a predikce klienta běží dál, dokud ji nezkoriguje další. To je teleport, zásah, který se nezaregistruje, a dveře, které se otevřou dvakrát. Proč si téměř každá akční hra vybrala UDP a co to stojí, vysvětluje TCP versus UDP for game servers.

Odkud ztráty doopravdy pocházejí, zhruba podle četnosti:

1. Nasycený uplink, obvykle hráčův vlastní. Plná odchozí fronta zahazuje pakety, jakmile je buffer plný, což je vyvrcholení výše popsaného bufferbloatu.
2. Wifi nebo špatný kabel. Poškozený kabel nebo nesoulad duplexu vyvolá malou, stálou ztrátu, kterou nic jiného nevysvětlí.
3. Přetížený spoj někde uprostřed, který se objevuje každý den ve stejnou dobu.
4. Přetékání vlastních socket bufferů serveru, když proces nestíhá číst. Na Linuxu netstat -su ukáže chyby přijímacího bufferu, a to jsou pakety, které stroj přijal a zahodil.
5. MTU blackhole, což vůbec není ztráta, ale u velkých paketů vypadá stejně. Otestuj to přímo: ping -M do -s 1472 play.example.com na Linuxu nebo ping -f -l 1472 play.example.com na Windows pošle paket o velikosti 1500 bajtů, který se nesmí fragmentovat. Pokud malé pingy fungují a tenhle ne, trasa neunese pakety plné velikosti a příčinou je obvykle někde tunel.

Když je to server, ne síť#

Tato kategorie se diagnostikuje špatně nejdráž, protože lidé kupují větší tarif, aby opravili router ve vlastním obýváku, nebo přesouvají server, aby opravili plugin.

Test je jednořádkový: pokud je ping na server plochý a nízký a hra přesto cuká, síť je v pořádku. To, co cítíš, je server, který nestíhá dokončit práci v rámci ticku.

Běžné příčiny:

• CPU na limitu. Jeden kontejner, tvrdé omezení na podíl, který sis koupil, a herní smyčka, která nestíhá. Server na 100 % je pomalý, ne rozbitý. Jak to číst poctivě, vysvětlují CPU versus RAM for game servers a reading a server load graph.
• Jeden drahý tick. Autosave zapisující velký svět, nárazová generace chunků, plugin dělající práci s databází na hlavním vlákně. V Minecraftu se to projeví jako špičky MSPT, ne trvalá zátěž, a najde to spark - diagnosing lag with spark.
• Tlak na paměť. Pauza garbage collectoru zastaví svět na tak dlouho, jak potřebuje, a server na limitu paměti je na tom hůř než ten s rezervou. Případ Minecraftu rozebírá Why TPS drops.
• Hlučný soused na sdíleném hardwaru, který vypadá jako občasné zpomalení bez lokálního vysvětlení - shared CPU and noisy neighbours.

Na RE:NODE konzole panelu vykresluje paměť, CPU a disk proti limitům tarifu, což je nejrychlejší způsob, jak oddělit „mému serveru dochází CPU“ od „moje síť zahazuje pakety“, než za cokoli z toho zaplatíš. O tom, co stojí za to mít připravené, než přijdou stížnosti, je monitoring that tells you something.

Co můžeš opravit, popořadě#

Nejlevnější a nejúčinnější první. Většina skupin skončí po třetím kroku.

1. Měř, než cokoli změníš. Ping na sto paketů a jeden mtr od každého stěžujícího si hráče. Zapiš si čísla. Polovina všech hlášených lagů je jeden člověk na wifi.
2. Připoj kabelem nejhlasitějšího stěžovatele. Nestojí to nic a překvapivý podíl stížností na jitter to vyřeší samo.
3. Oprav bufferbloat na routeru. Také zdarma, také nedostatečně využívané a řeší večerní stížnosti, které souvisejí s někým dalším v domácnosti.
4. Dokaž, kde ztráta vzniká, z obou směrů. Ztráta na zpáteční cestě není z hráčovy strany vidět. Pokud leží uvnitř sítě jednoho poskytovatele, jedinou skutečnou nápravou je tiket u něj s přiloženým reportem z mtr.
5. Dej server tam, kde je většina tvých hráčů. Latence je vzdálenost a nic to nezmění. RE:NODE provozuje jednu lokalitu, Německo, což je rozumný střed pro hráče z Gruzie, Turecka a východní i západní Evropy a špatná volba pro skupinu v Austrálii. Poctivou verzi tohoto rozhodnutí najdeš v článku Choosing where your server lives.
6. Oprav rozpočet ticku serveru, pokud čísla říkají, že problém je v serveru: view distance, počty entit, plugin, který pracuje v každém ticku.
7. Smiř se s minimem. Když je ping stálý a odpovídá vzdálenosti, je to číslo, které trasa dává, a žádný tarif, tick rate ani protokol to nezmění.

FAQ#

Jaký ping je pro herní server dobrý?

Pod 30 ms se od lokálního skoro u všeho nedá rozeznat. 30 až 60 ms je v pořádku pro survival, stavění a roleplay a ve střílečce je to znát, když se člověk dívá. 60 až 100 ms je hratelné a je to bod, kde si kompetitivní hráči začínají stěžovat. Nad 120 ms je to jiný zážitek, ne horší verze téhož.

Kolik packet lossu je přijatelných?

Pod 0,1 % si nikdo ničeho nevšimne. Okolo 1 % působí střílečka nespolehlivě. Nad 2 % je rozbitá. Shluková ztráta je mnohem horší než stejné procento rozložené rovnoměrně, takže posuzuj podle vzoru, ne podle titulního čísla.

Proč mám dobrý ping, a hra přesto cuká?

Protože zpoždění není na síti. Buď server vynechává ticky, což je problém CPU nebo pluginu, nebo klient zahazuje snímky, což je problém lokální. Plochý ping spolu se cukající hrou je nejjasnější signál, že síť na vině není.

Sníží upgrade hostingového tarifu ping?

Ne. Latenci určuje vzdálenost a větší tarif stroj nepřesune. Víc CPU pomůže, když server nestíhá dokončit své ticky, což je jiný příznak, ke kterému se vztahuje podobná stížnost.

Je horší jitter, nebo vysoká latence?

Jitter, s velkým náskokem. Herní klienti jsou stavěni na to, aby skryli stálé zpoždění, ale nedokážou skrýt kolísavé. Stabilních 90 ms se hraje líp než připojení s 40 ms, které každých pár vteřin vyskočí na 200.

Může VPN snížit můj lag?

Někdy, a jen když je problémem špatná trasa, ne vzdálenost. VPN může dát tvůj provoz na lépe propojenou cestu, ale stejně snadno může přidat hop a frontu. Vyzkoušej obojí, v denní dobu, kdy se problém děje.