한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › L7 Server-OS (Kernel)

Sprung der Systemuhr (NTP-Step) Wall-clock jump (NTP step)

Ursachen-ID so-timejump · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Wird die Serveruhr auf einen Schlag um einige Sekunden vor- oder zurückgestellt, lösen Timer, die von der Systemuhr abhängen, gesammelt aus oder bleiben stehen.

Warum Zeitsynchronisation stellt die Uhr auf einen Schlag stark um → Folge Timer lösen gesammelt aus oder bleiben stehen, Timeouts werden falsch erkannt → Auf dem Bildschirm Fehler bei Buffs und Cooldowns, Verbindungsabbrüche bei allen zugleich, Zeitraffer

Symptome
Zeitraffer, Verbindungsabbruch, Verschluckte Aktion / Rollback
Faktoren
Stillstand
Wer ist betroffen
Ganzer Server
Wann
Gelegentlich, zufällig
Zuständigkeit
Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Aufgaben Entwicklungsteam
Verstrichene Zeit, Timeouts und Cooldowns mit einer Monotonic Clock berechnen, die weder springt noch zurückläuft, die Wall Clock nur für Anzeige und Protokollierung nutzen.
Aufgaben Infrastrukturteam
Uhr langsam nachführen (makestep von chrony nur direkt nach dem Start), Zustand der Zeitsynchronisation (Uhrenabweichung) überwachen.
Größenordnungen
ntpd stellt die Uhr bei einer Abweichung über 0,128 s auf einen Schlag. Kleinere Abweichungen gleicht er langsam aus, und zwar so langsam, dass 1 s Abweichung gut 30 Minuten braucht. Das heute verbreitete chrony stellt mit der empfohlenen Einstellung (makestep) nur einige Male direkt nach dem Start auf einen Schlag und gleicht danach langsam aus. Auch wenn eine virtuelle Maschine kurz angehalten wird und wieder aufwacht, springt die Uhr.
Im Graphen
Vereinzelte Spitzen ohne Muster · Ausgelöste Timer und Verbindungsabbrüche, Protokoll der Uhrenkorrekturen
Wo nachsehen
Im Log des Zeitsynchronisationsdienstes nach großen sprunghaften Korrekturen suchen und mit dem Zeitpunkt der Auffälligkeit abgleichen. chrony schreibt Korrekturen, die größer als der Wert von logchange sind (Standard 1 s), ins syslog
Spricht dafür
Zum Zeitpunkt der Fehler bei Buffs und Cooldowns, der gleichzeitigen Verbindungsabbrüche oder des Zeitraffers ist eine Uhrenkorrektur protokolliert, und ihre Größe entspricht etwa dem Ausmaß der Auffälligkeit
Spricht dagegen
Keine Uhrenkorrektur protokolliert: diese Ursache scheidet aus. Bei VMs auch prüfen, ob sie angehalten wurden und wieder aufgewacht sind („Wartung des Cloud-Hosts und Live-Migration“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

  1. ntpd - Network Time Protocol (NTP) daemon Network Time Foundation
    Abweichungen über der Step-Schwelle von 128 ms werden auf einen Schlag korrigiert, kleinere langsam mit 0,5 ms pro Sekunde, sodass 1 s Abweichung 2.000 s (ca. 33 Minuten) braucht
  2. chrony – Frequently Asked Questions chrony
    Empfohlen ist, Steps nur einige Male direkt nach dem Start zu erlauben, etwa mit makestep 1 3, eine angehaltene und fortgesetzte VM kann mit falscher Uhrzeit aufwachen
  3. clock_gettime(2) — Linux manual page Linux man-pages
    CLOCK_MONOTONIC ist von unstetigen Sprüngen der Systemuhr nicht betroffen und läuft nie rückwärts
  4. chrony.conf(5) chrony
    logchange: Korrekturen der Uhr, die größer als dieser Wert sind (Standard 1 s), werden ins syslog geschrieben

Verwandte Ursachen

Gleiche Schicht: L7 Server-OS (Kernel)

Ursachen aus anderen Schichten mit demselben Symptom (Zeitraffer)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen