Game-latency verlagen: locatie, route en code

Game-latency bepaalt het grootste deel van de vertraging die een speler op het scherm voelt, en die komt zelden door één oorzaak: het zijn meerdere lagen van vertraging die op elkaar gestapeld zijn. Een praktische aanpak is het werk in drie gebieden te splitsen: een locatie kiezen die fysiek dicht bij je spelers ligt, de netwerkroute die een pakket aflegt verbeteren, en de tick-lus en pakketstroom in de eigen code van de server afstemmen. Dit artikel behandelt alle drie met echte, toepasbare stappen.

Waar komt latency vandaan?

De vertraging die een speler ziet is eigenlijk de som van meerdere onderdelen:

• Propagatievertraging: de afstand die het signaal over glasvezel aflegt. Licht beweegt door glas met ongeveer 200.000 km/s, dus zelfs 3.000 km betekent al ~15 ms basisvertraging voor één richting. Dit kun je niet wegwerken in code; je verkleint het alleen door de afstand te verkorten.
• Wachtrij- en verwerkingsvertraging: de tijd dat een pakket wacht in routers onderweg, in de netwerkkaart van de server en in de game-lus.
• Serialisatievertraging: de tijd om het pakket op de lijn te schrijven, merkbaar bij grote pakketten op lage bandbreedte.
• Tick-vertraging: omdat de server de toestand op vaste intervallen bijwerkt, kan binnenkomende invoer tot de volgende tick wachten.

Het doel is een paar milliseconden te winnen in elke laag die je beheert, want ze tellen op.

1. De juiste locatie kiezen

De grootste en goedkoopste winst komt meestal door de server dichter bij je spelersbasis te brengen. Als de meeste spelers in Turkije en Europa zitten, bespaart een server in een centrale regio als Frankfurt, Amsterdam of Istanbul tientallen milliseconden ten opzichte van een datacenter in de VS. Eén goede beslissing kan meer uitmaken dan alle latere optimalisaties samen.

Meet een locatie echt voordat je je eraan vastlegt. Om de basis-retourtijd vanuit de doelregio te zien:

ping -c 20 server-ip
mtr -rwzc 50 server-ip

Kijk in de mtr-uitvoer naar pakketverlies en latency-pieken bij elke hop; zo onderscheid je of het probleem afstand is of een slechte tussenliggende carrier. Strekt je spelersbasis zich uit over meerdere continenten, dan is het juiste antwoord regionale servers die elke speler naar de dichtstbijzijnde leiden, niet één gigantische server.

2. De netwerkroute verbeteren

Zelfs als de geografische afstand tussen twee punten kort is, volgt internetverkeer soms een lange, slechte route. Met mtr of traceroute spoor je onnodige omwegen op of een transitprovider met frequent pakketverlies.

• Provider- en peering-kwaliteit: kies een host met goede peering-afspraken die dicht bij de ISP's van je spelers verbindt. Zelfs in hetzelfde datacenter nemen verschillende providers andere routes.
• Gebruik UDP: voor realtime game-verkeer schaden TCP's hertransmissie- en geordende-leveringsgaranties meestal — wachten op een verloren, verouderd positiepakket vertraagt het nieuwe. De meeste games bouwen hun eigen betrouwbaarheidslaag boven op UDP.
• MTU en fragmentatie: houd pakketten onder de pad-MTU (meestal 1500 bytes, lager met tunnels) zodat fragmentatie en de bijbehorende extra vertraging nooit optreden.

3. Besturingssysteem- en socketinstellingen

Aan de Linux-kant verkorten enkele instellingen hoelang de server een pakket vasthoudt. Het belangrijkste is het uitschakelen van Nagle's algoritme, dat kleine pakketten samenvoegt en dus zichtbare vertraging toevoegt aan interactief verkeer:

int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

Houd voor UDP-sockets de verzend-/ontvangstbuffers groot genoeg om bursts te weerstaan en stuur de socket in non-blocking modus met epoll. Onder belasting is een overlopende buffer die pakketten laat vallen een veelvoorkomende oorzaak van pieken in de ping. Stem kernelparameters als net.core.rmem_max af op de echte belasting, niet blindelings.

4. Tick rate en de game-lus

De server werkt de wereld bij op een vaste frequentie (tick rate). Een lus van 20 Hz zet elke 50 ms een stap; 60 Hz elke ~16,7 ms. Een hogere tick rate verkort hoelang invoer wacht op verwerking maar verhoogt de CPU-kosten. In de praktijk geven snelle games de voorkeur aan 30–60 Hz.

Wat telt is dat de lus vast en voorspelbaar blijft. Een nette vaste tijdstap ziet er zo uit:

const double dt = 1.0 / 30.0; // 30 Hz
double accumulator = 0.0;
double last = now();
while (running) {
    double current = now();
    accumulator += current - last;
    last = current;
    while (accumulator >= dt) {
        update(dt);     // de simulatie vooruit zetten
        accumulator -= dt;
    }
    flush_outgoing();   // toestand meteen versturen
}

Het cruciale punt hier is de toestand direct na update te versturen in plaats van te bufferen; anders geef je de tick-winst terug in een kunstmatige wachtrij. Verplaats ook zwaar werk binnen een tick (database-schrijfacties, bestands-I/O, logging) naar een aparte thread van de hoofdlus, zodat één trage query niet alle spelers bevriest.

5. Bandbreedte en jitter beheren

Net zo belangrijk als de ruwe ping is jitter — de variatie in vertraging. Een stabiele 60 ms voelt beter dan een ping die voortdurend tussen 20 en 120 springt. Om jitter te verminderen:

• Verklein toestandsupdates met delta's (alleen versturen wat veranderde); minder data betekent minder serialisatievertraging.
• Houd de verzendsnelheid per speler stabiel; plotselinge verkeerspieken blazen wachtrijen op.
• Gebruik een kleine interpolatiebuffer aan de clientzijde om netwerkschommelingen glad te strijken.

Veelgestelde vragen

Verlaagt het verhogen van de tick rate de ping?

Niet de netwerk-ping direct; netwerkvertraging gaat over afstand en route. Maar omdat het verkort hoelang invoer wacht op verwerking, vermindert het de totale vertraging die de speler voelt. Stabiel en laag is belangrijker dan hoog.

Moet ik UDP of TCP gebruiken?

UDP voor realtime positie-/invoerverkeer. TCP's geordende levering schaadt omdat wachten op een oud pakket het nieuwe vertraagt. Waar betrouwbaarheid nodig is (belangrijke gebeurtenissen bijvoorbeeld), bouw je je eigen lichte bevestigingslaag boven op UDP.

Mijn spelers zitten op verschillende continenten — wat doe ik?

Je kunt niet iedereen tevreden stellen met één server. Draai regionale servers en leid elke speler naar die met de laagst gemeten ping; fysieke afstand versla je niet met code.

Is de ping van je server te hoog? Ik kan je helpen vertraging op te sporen op het gebied van locatie, netwerkroute en de game-lus en die om te zetten in een meetbare verbetering. Neem contact op en laten we samen naar je opzet kijken.