Waarom latency telt voor gameservers en de spelerservaring

Wat latency met een multiplayergame doet

Latency is de vertraging tussen het moment dat een speler iets doet en het moment dat de gamewereld daarop reageert. Haal de trekker over, en er zit een gat voordat de server erkent dat je geschoten hebt, beslist of je raak schoot en elke andere client vertelt wat er gebeurde. Houd dat gat klein en constant en de game voelt strak: schoten landen waar je richtte, beweging is scherp, andere spelers bewegen vloeiend. Laat het groeien of schommelen en dezelfde game voelt stroperig, oneerlijk of kapot, terwijl er op geen enkele machine iets misging.

Het nuttigste om te begrijpen is dat ping niet het hele verhaal is. Ping meet één deel van de reis, de round trip over het netwerk. Wat een speler voelt is een langere keten, waarin ook zit hoe vaak de server de wereld bijwerkt, hoe de client de vertraging maskeert en of de verbinding stabiel is of jittert. Een server kan een prima ping laten zien en toch beroerd aanvoelen, en een server op tweeduizend kilometer afstand kan voor het juiste genre prima aanvoelen.

Voor een host is het antwoord in één regel kort: zet de server dicht bij je spelers, op hardware die zijn tick rate onder belasting vasthoudt. De rest van dit artikel legt uit waarom die twee dingen domineren, en wat je aan de rest wel en niet kunt doen.

Dit artikel hoort bij onze gids over gameservers op bare metal en de diepere blik op gameprestaties op bare metal tegenover virtualisatie. Hier is de focus smaller: waar vertraging vandaan komt en hoe die bij de speler aankomt.

De opbouw van een round trip

Als een speler klikt, is de vertraging die hij voelt de som van een aantal fasen, en maar een deel daarvan is het netwerk. Eén input gevolgd van muis tot scherm:

1. Input sampling. De client leest muis en toetsenbord uit volgens zijn eigen schema. Je klik kan een frame of twee blijven liggen voordat de gameloop hem überhaupt leest. Bij 120 fps is dat een paar milliseconden; bij 30 fps meer dan 30.
2. Verzenden door de client. De client verpakt de input en verstuurt hem. Ook clients bundelen en versturen in hun eigen ritme, dus er kan een korte wachttijd zijn voordat het pakket vertrekt.
3. Last mile. Het pakket gaat over de eigen verbinding van de speler: wifi, thuisrouter, het toegangsnetwerk, tot aan de eerste echte hop. Hier ontstaat veel van de latency bij consumenten en de meeste jitter.
4. Transit en peering. Het pakket gaat over een of meer netwerken om het netwerk van de server te bereiken. Hoe direct dat gaat, hangt af van peering: een goed gepeerd pad geeft het verkeer over op een internet exchange in dezelfde regio, een slecht pad maakt eerst een omweg via een ander land.
5. Wachtrij op de server. Het pakket komt aan en wacht tot het gameproces het leest.
6. Tick alignment. Deze fase vergeten mensen. De server doet niets met je input op het moment dat die binnenkomt. Hij verwerkt hem in de volgende simulatietick. Tickt de server 20 keer per seconde, dan kan je input tot 50 ms op de volgende tick wachten voordat er iets mee gebeurt, hoe snel het netwerk ook was.
7. Verwerking. De tick draait de simulatie: hij past je input toe, handelt hits af, verplaatst entiteiten en bepaalt de nieuwe toestand van de wereld. Is de server overbelast en duurt een tick langer dan zijn budget, dan rekt deze fase uit en voelt elke speler dat tegelijk.
8. Terugweg. De server stuurt de bijgewerkte toestand terug, en de hele netwerkreis gebeurt in omgekeerde richting voordat je scherm het resultaat toont.

Ping meet ruwweg fase drie, vier en acht, en verder niets. Daarom is ping nodig maar niet voldoende. Twee servers met precies dezelfde ping van 30 ms kunnen verschillend aanvoelen omdat fase één, twee, zes en zeven verschillen. Vooral tick alignment is onzichtbaar voor ping, en bij een game met een lage tick rate vaak groter dan de netwerkvertraging.

Tick rate en latency zijn twee verschillende klokken

Een server simuleert de wereld in afzonderlijke stappen, ticks genoemd. De tick rate is het aantal van die stappen per seconde, en die bepaalt de korrel van alles wat de server doet. Het is een aparte klok naast de netwerklatency, en je moet ze allebei kort houden.

De rekensom is eenvoudig. Minecraft draait zijn wereld op 20 ticks per seconde, één tick per 50 ms, volgens het tickmodel van de game zelf. Dus zelfs op een server in hetzelfde gebouw kan een Minecraft-input tot 50 ms op de volgende tick wachten, en redstone-timing loopt in stappen van 50 ms. Dat is geen lag door een slechte host; zo is de game ontworpen.

Competitieve shooters draaien veel sneller, omdat ze een fijnere timing nodig hebben. Riot bouwde Valorant op 128-tick-servers, één tick per 7,8 ms, speciaal zodat een verdediger tijd heeft om te reageren op een aanvaller die om een hoek peekt. Counter-Strike 2 koos een andere weg: de servers draaien op 64 tick, maar Valve voegde een subtick-systeem toe dat elke input tot op de milliseconde van een tijdstempel voorziet en hem toepast op het moment dat hij plaatsvond, in plaats van hem af te ronden naar de volgende tick. Dat moet het grootste deel van het verschil met een echte 128-tick-ervaring dichten. Of dat volledig lukt, is onder spelers nog steeds een discussie, maar de bedoeling van het ontwerp is duidelijk: de vertraging door tick alignment verkleinen zonder het werk van de server te verdubbelen.

Survival- en sandboxgames zitten lager en leunen op instelbaarheid. Rust en ARK bieden de tick rate aan als serverinstelling, en door de community beheerde instances laten die vaak rond de 30 staan: minder responsiviteit in ruil voor CPU-ruimte op machines die grote werelden hosten. Het gaat niet om het exacte getal voor één titel, dat per patch verandert; het gaat om het patroon.

Tick rates veranderen tussen gameversies en zijn bij zelf gehoste titels instelbaar; lees dit als de ruwe vorm, niet als specificatieblad. Controleer het actuele getal voor jouw versie voordat je het citeert.

Een hogere tick rate verkort de wachttijd door tick alignment en verder niets. De lijn wordt er niet korter van. Een 128-tick-server op het verkeerde continent laat spelers nog steeds op de round trip wachten; een 20-tick-server in de juiste stad laat ze nog steeds 50 ms op de volgende tick wachten. Beide klokken zijn echt, en een goede host let op allebei.

Hoe netcode de vertraging verbergt, en waar de illusie breekt

Geen tick rate of peering brengt latency naar nul, dus games liegen in plaats daarvan overtuigend. Netcode is de verzameling trucs die de vertraging voor de speler verbergt. Vier daarvan wegen het zwaarst.

Client-side prediction. In plaats van te wachten tot de server je beweging bevestigt, toont de client die meteen, met een voorspelling van wat de server vrijwel zeker goedkeurt. Je personage beweegt op het moment dat je vooruit drukt. Komt de gezaghebbende update van de server binnen en klopt die, dan merk je niets. Wijkt hij af, dan corrigeert de client.

Entity interpolation. De posities van andere spelers komen binnen als losse snapshots, met de tick rate als tussenruimte en ruwer gemaakt door het netwerk. Om ze vloeiend te tekenen, houdt de client een kleine buffer aan en rendert hij ze iets in het verleden, geïnterpoleerd tussen de laatste twee bekende posities. Daarom zien andere spelers er vloeiend uit, zelfs op een bescheiden verbinding. Het betekent ook dat je iedereen altijd een tel achter ziet op waar ze op de server werkelijk zijn.

Lag compensation. Als je schiet, spoelt een server-authoritative game zijn eigen toestand terug met jouw latency om het schot te beoordelen tegen de plek waar het doelwit op jouw scherm stond toen je schoot, niet waar het nu staat. Riot beschrijft precies dit terugspoelen in zijn artikel over de netcode. Zonder lag compensation zouden spelers met een hoge ping nooit een bewegend doelwit raken. Met lag compensation krijgen ze een eerlijke kans.

Rollback. Fighting games, die geen enkele inputvertraging verdragen, gebruiken rollback-netcode. De client neemt de volgende inputs van de tegenstander aan, simuleert zonder vertraging vooruit, en als de gok fout was, zet hij de spelstatus terug, simuleert opnieuw vanaf het punt waar het uiteenliep en spoelt dan door naar nu. De techniek werd populair gemaakt door de GGPO SDK en is inmiddels de norm voor competitieve fighters. Goed uitgevoerd voelt online spelen als lokaal spelen, tot de verbinding zo slecht wordt dat de correcties zichtbaar worden.

De illusie breekt op voorspelbare plekken, en elke speler kent ze:

• Peeker's advantage. De speler die om een hoek beweegt, ziet de stilstaande verdediger eerder dan de verdediger hem ziet, omdat interpolatie en de round trip ervoor zorgen dat de client van de verdediger het verleden toont. Samen met lag compensation wint de peeker vaak het duel. Riot noemt dit als de concrete reden waarom het voor 128-tick-servers koos.
• De discussie over wie eerst schoot. Je duikt achter dekking en gaat een moment later dood. Op jouw scherm was je veilig; op het scherm van de schutter, teruggespoeld door lag compensation, stond je nog open toen hij schoot. De server volgde zijn beeld. Niemand speelde vals.
• Rubber-banding en warping. Als de voorspelling fout is of updates verdwijnen, trekt de correctie je personage, of een andere speler, terug naar waar de server zegt dat die hoort te staan. Die ruk terug is de illusie die live faalt, en de oorzaak is bijna altijd packet loss of een jitterende verbinding, niet de ping zelf.

Hoeveel latency elk genre kan verbergen

Netcode levert in elk genre een andere hoeveelheid speling op, dus er is geen enkel getal voor "acceptabele" latency. Het meest geciteerde kader is het model van Claypool en Claypool uit 2006 in Communications of the ACM, dat de latencytolerantie van een game koppelt aan het perspectief van de speler en aan hoe precies en tijdkritisch diens acties zijn.

Hun bevinding, in ronde getallen: first-person games zoals shooters en racegames, waarin je een avatar direct bestuurt en onder krappe deadlines handelt, gaan rond 100 ms achteruit. Third-person games met een avatar, zoals veel rollenspellen, blijven speelbaar tot ongeveer 500 ms, omdat acties minder tijdkritisch zijn. Omnipresente games, waarin je van bovenaf eenheden aanstuurt zoals in real-time strategy, verdragen het meest; later onderzoek naar het genre legt een bruikbare bovengrens rond 1.000 ms, omdat een bevel geven geen reflex is.

Wat je in de praktijk uit dat onderzoek haalt, los van de exacte drempels:

• Competitieve shooters en fighters vergeven het minst. Spelers merken tientallen milliseconden, en consistentie telt net zo zwaar als het gemiddelde. In dit genre is de serverlocatie zo goed als niet onderhandelbaar.
• MOBA's en action-RPG's zitten in het midden. Ze verbergen meer vertraging via voorspelling en minder tijdkritische inputs, maar competitief spel beloont nog steeds een lage, stabiele latency.
• MMO's en strategiegames verdragen het meest. Turn-based en tragere real-time games kunnen spelers over een heel continent spreiden en nog steeds goed spelen.

Lees dit als richting. De getallen verschuiven met de specifieke game, de vaardigheid van de speler en de kwaliteit van de netcode. De veilige ontwerpregel: kies locatie en hardware van de server voor het meest latencygevoelige wat je spelers erop gaan doen.

Waarom jitter en packet loss meer pijn doen dan een stabiele hogere ping

Bij latency gaat het niet alleen om hoe hoog, maar ook om hoe stabiel. Een verbinding die vlak op 80 ms blijft, voelt meestal beter dan een die gemiddeld 50 ms haalt maar wild heen en weer schiet, en de reden is de netcode uit de vorige sectie.

Interpolatie en voorspelling gaan allebei uit van een ongeveer constante vertraging. Geef ze een stabiele ping en ze vinden een ritme; de buffergrootte en het correctieritme liggen vast, en de timing van de speler zelf past zich aan. Jitter breekt dat. Als de round trip heen en weer springt tussen 40 ms en 120 ms, kan de client geen buffer kiezen die tegelijk klein en veilig is, dus vergroot hij de buffer, wat voor iedereen vertraging toevoegt, of houdt hij hem krap en krijgt hij snapshots die te laat binnenkomen en als haperingen zichtbaar worden.

Packet loss is nog erger. Een verloren update is geen vertraagd frame; het is een ontbrekend frame. De client houdt de laatst bekende toestand vast, waardoor een andere speler midden in een pas bevriest, of extrapoleert voorbij die toestand en springt terug zodra de werkelijke positie binnenkomt. Die sprong is rubber-banding. Een constant verlies van 1 tot 2 procent laat een game kapot aanvoelen bij een ping die anders uitstekend zou zijn.

De ontwerples voor een host: een goed gepeerd pad met stabiele timing verslaat een iets korter pad dat congestie krijgt. Een route die af en toe een link verzadigt en pakketten laat vallen, voelt slechter dan een marginaal langere route die dat nooit doet.

Geografie en routing bepalen het grootste deel

Van alles waar een host invloed op heeft, is fysieke afstand het grootst en het minst onderhandelbaar. Licht in glasvezel reist met ongeveer twee derde van zijn snelheid in vacuüm, zo'n 200 km per milliseconde, wat de handige vuistregel oplevert van ongeveer 1 ms round-trip-vertraging per 100 km kabel, vóór enige routing-overhead. Amsterdam naar Frankfurt is een paar milliseconden op de lijn; Amsterdam naar Sydney kan niet minder zijn dan ongeveer 150 ms enkele reis, wat je ook betaalt, omdat de planeet nu eenmaal zo groot is.

Routing bepaalt hoe dicht je werkelijk bij die fysieke ondergrens komt. Twee servers op dezelfde afstand kunnen tientallen milliseconden verschillen, afhankelijk van hoe hun verkeer wordt vervoerd. Een goed gepeerd netwerk geeft verkeer direct over aan andere netwerken op een internet exchange in dezelfde regio en houdt het pad zo kort. Een slecht verbonden netwerk leunt op transit die je pakketten mogelijk eerst via een verre stad stuurt voordat ze terugkomen, met extra latency en extra hops waar pakketten verloren of vertraagd kunnen raken. Daarom staat onze peering openbaar op onze netwerkpagina: het pad is onderdeel van het product.

De conclusie voor een host is kort. Serverlocatie weegt zwaarder dan elke andere latencyknop die je in handen hebt, omdat die de ondergrens bepaalt waarbinnen tick rate en netcode daarna werken. Een Europese spelersbasis hoort bediend te worden vanaf een goed verbonden Europese locatie, niet over een oceaan gerouteerd naar waar capaciteit het goedkoopst was. Daarom bestaat onze locatie in Amsterdam als aparte keuze: voor spelers in Europa haalt hosten daar meer gevoelde latency weg dan welke tuning op de machine zelf ook.

De latency die je als host zelf in de hand hebt

Afstand en routing leggen de ondergrens. In de serverfasen van de round trip houdt een host die ondergrens vast of verpest hij hem, en dat is het deel dat je zelf beheert.

Het grootste risico aan de serverkant is een tick die over zijn budget heen gaat. Een 20-tick-server heeft 50 ms om elke tick af te ronden; een 64-tick-server ongeveer 15 ms. Kan de simulatie niet binnen dat venster klaar zijn, dan schuiven ticks op, daalt de effectieve rate, en voelt elke verbonden speler op hetzelfde moment extra vertraging. Dat bedoelen mensen meestal met "de server laggt", los van de ping van één speler. Het is een CPU-probleem, en gamesimulaties leunen op single-thread-prestaties, en daarom winnen snelle cores het voor deze workload van veel trage cores. Die afweging behandelen we in het artikel over prestaties op bare metal tegenover een VM.

Overboekte gedeelde hosting is de gebruikelijke manier waarop dit misgaat. Als een provider te veel instances op één fysieke machine propt, concurreert je gameproces om CPU-tijd waarvan het dacht dat die van hem was. Op gevirtualiseerde hosts zie je dat als CPU steal: cycli die de hypervisor aan een buur geeft in plaats van aan jou. Steal time wordt opgeschoven ticks, en opgeschoven ticks worden gevoelde latency voor elke speler op je server, zonder dat het netwerk er iets aan kan doen. Een dedicated machine haalt de buur helemaal weg, en dat is het belangrijkste latencyargument voor gameservers op bare metal.

Aanvallen zijn ook een bron van latency, niet alleen van downtime. Een volumetrische DDoS-aanval die de uplink verzadigt, drijft latency en packet loss voor legitieme spelers op, lang voordat de server volledig offline gaat; de game voelt alsof hij verdrinkt in jitter. Mitigatie die de flood upstream wegfiltert, houdt het pad schoon, en dat is net zo goed een latencyvoordeel als een beschikbaarheidsvoordeel.

De rest is gewone hostingdiscipline: geef het gameproces de cores die het nodig heeft, houd de tickloop binnen budget, en laat geen achtergrondtaak of luidruchtige medehuurder tijdens piekuren cycli stelen.

Goed meten

Als je latency diagnosticeert, is één pinggetal het minst bruikbare gereedschap, omdat het het hele pad in één cijfer samenvat en verbergt waar de vertraging zit.

ping geeft je de round trip naar de server en, als je het een tijdje laat lopen, een indruk van jitter en verlies. Het beantwoordt "hoe ver en hoe stabiel", en niets over het pad.

ping -c 50 203.0.113.10

mtr combineert traceroute en ping: het pingt elke hop langs het pad continu en toont verlies en latency per hop. Dat vertelt je waar het probleem zit. Verschijnen latency en verlies bij hop 3 en blijven ze hoog tot aan de server, dan zit het probleem vroeg, dicht bij de speler. Is alles schoon tot de laatste hop, kijk dan naar de server. Toont één hop in het midden verlies maar zijn de hops erna schoon, dan beperkt die hop waarschijnlijk alleen zijn eigen ICMP-antwoorden en kun je hem negeren.

                             Packets               Pings
 Host                       Loss%   Snt   Avg  Best  Wrst
 1. 203.0.113.1              0.0%    50   0.5   0.3   1.2
 2. 198.51.100.9             0.0%    50   3.4   2.9   9.8
 3. 198.51.100.40            0.0%    50  11.5  10.9  24.6
 4. 192.0.2.50               0.0%    50  18.9  18.3  31.4

De net graph in de game is de meting die overeenkomt met wat de speler voelt, omdat die de tick alignment en de serververwerking meeneemt die ping niet ziet. De meeste competitieve titels hebben er een: die toont de latency van client naar server, de interpolatievertraging, packet loss en vaak de tickprestaties van de server zelf. Als de ping van een speler er goed uitziet maar de game slecht aanvoelt, laat de net graph meestal de echte boosdoener zien: een uitgerekte interpolatiebuffer of een server waarvan de tick rate is gezakt.

De getallen hierboven zijn illustratief en gebruiken IP-bereiken die voor documentatie zijn gereserveerd. Je eigen waarden verschillen per locatie, route en tijdstip; draai de commando's tegen je eigen server en lees de vorm van het resultaat, niet deze cijfers.

Deployen op Serverside.com

Latency wordt grotendeels bepaald voordat de eerste speler verbinding maakt, door waar de server staat en hoe zijn netwerk gerouteerd is. Een Serverside.com-gameserver draait op bare metal in ons eigen netwerk (AS55285), dus je tickloop krijgt een hele machine zonder luidruchtige buur die cycli steelt, en het pad naar je spelers loopt over routing die wij peeren en publiceren in plaats van over de transit die het goedkoopst was. Altijd actieve DDoS-mitigatie staat vóór de publieke interface, zodat een flood geen jitter wordt voor de spelers die er echt zijn. Provisioning duurt minder dan een minuut, dus je kunt een machine op de juiste plek zetten en de route testen voordat je je vastlegt.

Voor een Europese spelersbasis is onze locatie in Amsterdam degene die de meeste gevoelde latency weghaalt, goed gepeerd op de exchanges in de regio, zodat de tijd op de lijn naar spelers in de EU dicht bij de fysieke ondergrens blijft. Wil je eerst het volledige aanbod en alle locaties zien, begin dan bij de dedicated server configurator en kies de locatie die het dichtst bij de spelers ligt voor wie je bouwt.

FAQ

Wat is het verschil tussen ping en latency in een game?

Ping is één meting van latency: de round-trip-tijd van een klein pakketje naar de server en terug, meestal via ICMP. Latency zoals een speler die voelt is breder. Daar zit de ping in, plus de tijd dat je input wacht tot hij gesampled wordt, de tijd dat de server wacht op zijn volgende simulatietick voordat hij iets met je pakket doet, de verwerking in die tick en de terugweg. Twee spelers met dezelfde ping van 30 ms kunnen een verschillende vertraging voelen als de een op een 20-tick-server zit en de ander op een 128-tick-server, want het wachten op de tick hoort bij de gevoelde latency en ping meet dat niet.

Verlaagt een hogere tick rate de latency?

Hij verlaagt één specifiek onderdeel ervan. Een hogere tick rate verkort de gemiddelde wachttijd tussen het moment dat de server de wereld samplet en het moment dat hij je input verwerkt, omdat ticks vaker voorkomen. Een 20-tick-server werkt elke 50 ms bij, dus een input kan tot 50 ms blijven liggen voordat hij verwerkt wordt; een 128-tick-server werkt elke 7,8 ms bij, dus die wachttijd is veel kleiner. Wat een hogere tick rate niet verandert is de round trip over het netwerk. Staat de server 5.000 km verderop, dan lost geen enkele tick rate de ongeveer 50 ms op die het pakket per richting over de lijn onderweg is. Tick rate en netwerkafstand zijn twee aparte klokken, en je moet ze allebei kort houden.

Waarom verlies ik gevechten die ik dacht te winnen, zelfs met een lage ping?

Meestal is dat lag compensation in combinatie met peeker's advantage. Server-authoritative shooters spoelen de spelstatus terug met jouw latency om een schot te beoordelen, dus de speler die beweegt en om een hoek peekt, wordt vaak beoordeeld als degene die eerst schoot, omdat hij jou op zijn scherm zag voordat jouw scherm hem liet zien. De server respecteert wat elke client zag op het moment dat die handelde. Daarom wint degene die om de hoek komt meestal het duel, en daarom voelt de verdediger dat hij gedood werd nadat hij al terug in dekking was gedoken. Het is een ontwerpafweging, geen bug, en een lagere, stabielere latency aan beide kanten verkleint het verschil.

Is jitter of packet loss erger dan een hoge ping?

Voor de meeste games wel. Een stabiele 80 ms is voorspelbaar, en zowel de netcode als de timing van de speler zelf passen zich erop aan. Jitter, waarbij de round trip heen en weer schiet tussen bijvoorbeeld 40 ms en 120 ms, maakt die aanpassing onmogelijk, omdat de interpolatiebuffer en de voorspelling van de client zich niet op een vaste vertraging kunnen instellen. Packet loss is nog erger: een verloren update betekent dat de client de laatst bekende toestand bevriest, of extrapoleert en daarna corrigeert, en dat is precies wat rubber-banding en warping zijn. Een verbinding met een hogere gemiddelde ping die stabiel blijft, voelt meestal beter dan een verbinding met een lager gemiddelde die piekt en pakketten laat vallen.

Hoe dicht moet een gameserver bij mijn spelers staan?

Zo dicht dat de propagatievertraging binnen de tolerantie van je genre valt. Licht in glasvezel legt ongeveer 200 km per milliseconde af, dus als vuistregel geldt ongeveer 1 ms round-trip-vertraging per 100 km kabel, vóór routing-overhead. Voor een competitieve shooter wil je spelers binnen een paar honderd kilometer, zodat de tijd op de lijn onder de 10 ms blijft; een strategiegame of MMO kan veel breder spreiden. Voor een Europese spelersbasis betekent dat hosten op een goed gepeerde Europese locatie in plaats van iedereen over een oceaan te routeren, en dat is de grootste latency-beslissing die een host neemt.