Selbst Licht legt in Glasfaser nur etwa 200.000 km pro Sekunde zurück. Ein weit entfernter Server bleibt langsam, so gut er auch ist.
Warum Server steht weit entfernt (Auslandsserver, anderer Kontinent) → Folge Umlaufzeit wächst mit der Entfernung (mindestens 10 ms pro 1.000 km) → Auf dem Bildschirm Gleichbleibender Input-Lag bei jeder Aktion, Nachteil bei der Trefferabfrage
Physikalische Grenzen lassen sich per Code nicht beheben, nur abmildern: Regionsauswahl anbieten, damit Spieler einen nahen Server wählen, Nachteile bei der Trefferabfrage per Lag-Compensation (Zurückspulen) verringern.
Aufgaben Infrastrukturteam
Server/OS: in Regionen mit vielen Spielern eigene regionale Server betreiben. Netzwerk: Zugangspunkte (Edge) nahe bei den Spielern aufbauen, Leitungen und Routen mit wenig Umwegen wählen.
Größenordnungen
Seoul–Tokio etwa 30 ms, Seoul–Singapur etwa 75 ms, Seoul–US-Westküste etwa 140 ms, Seoul–Europa etwa 230–270 ms (hin und zurück, über reale Routen). Auf der direkten Linie nach Europa liegen kaum große Kabel. Der Traffic läuft über Südostasien und Suez oder über die USA, daher liegt der Wert weit über dem, was die Entfernung allein ergibt.
Im Graphen
Von Anfang an dauerhaft hoch · RTT (nach Land und Region)
Wo nachsehen
Verbindungs-IPs einem Land zuordnen und die RTT-Verteilung pro Land auswerten, dann von einer VM in der Cloud-Region vor Ort oder von RIPE-Atlas-Probes (nach Land und ASN ausgewählt) per ping und traceroute zum Server messen
Spricht dafür
RTT aus fernen Ländern ist unabhängig von der Tageszeit dauerhaft hoch und liegt nahe an der aus der Entfernung berechneten Mindestlatenz (10 ms hin und zurück pro 1.000 km) und an öffentlichen Latenzstatistiken
Spricht dagegen
Deutlich höher, als die Entfernung erklärt: „Umweg-Routing“. Steigt nur abends: „Überlast am Peering-Punkt zur Stoßzeit“
ITU-T G.114: One-way transmission timeITU Planungswert für die Ausbreitungsverzögerung in Glasfaser: 5 µs/km (etwa 200.000 km/s, 10 ms hin und zurück pro 1.000 km)
Azure network round-trip latency statisticsMicrosoft Azure Gemessene Median-RTT ab Seoul (Korea Central): Tokio 30 ms, Singapur 68 ms, US-Westküste 124–136 ms, Europa 234–244 ms
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen