遊戲 Lag 白皮書 › L7 伺服器 OS（kernel）
系統時鐘跳動（NTP step） Wall-clock jump (NTP step)
原因 ID so-timejump · 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
伺服器時鐘一次被往前或往後調整幾秒時，依賴系統時鐘的計時器會同時觸發或停住。
為什麼 時間同步一次大幅調整時鐘 → 於是 計時器集中觸發或停住，逾時判定出錯 → 畫面上 buff 與冷卻時間異常、大家同時斷線、快轉
- 症狀
- 快轉, 斷線, 吃指令／回檔
- 因素
- 停滯
- 誰會遇到
- 整個伺服器
- 何時
- 偶爾隨機發生
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 基礎設施團隊（伺服器基礎設施）
- 遊戲開發團隊要做的事
- 經過時間、逾時、冷卻時間都用不會跳動也不會倒退的單調時鐘（monotonic clock）計算，wall clock 只用於顯示與記錄。
- 基礎設施團隊要做的事
- 時鐘採漸進調整（chrony 的 makestep 只在剛啟動時使用），監控時間同步狀態（時鐘誤差）。
- 數值參考
- ntpd 在差距超過 0.128 秒時會一次校正，差距較小時則慢慢校正，速度是消除 1 秒差距要花 30 多分鐘。現在常用的 chrony 在建議設定（makestep）下，只在剛啟動時一次校正幾次，之後就慢慢校正。虛擬機器短暫暫停後恢復時，時鐘也會跳動。
- 圖表上
- 偶爾隨機飆高 · 計時器觸發次數與斷線次數、時鐘調整紀錄
- 查看位置
- 在時間同步服務的 log 中找出一次大幅調整時鐘的紀錄，與發生異常的時間點對照。chrony 調整幅度超過 logchange 設定值（預設 1 秒）時會寫入 syslog
- 符合的跡象
- buff 與冷卻時間異常、同時斷線、快轉發生的時間點有時鐘調整紀錄，且調整幅度與異常的大小相近
- 不符合的跡象
- 沒有時鐘調整紀錄就不是這個原因。在虛擬機器上時，也要查是否暫停後恢復（「雲端主機維護與即時遷移」）
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- ntpd - Network Time Protocol (NTP) daemon Network Time Foundation
差距超過 step 門檻 128ms 時一次校正，較小時慢慢校正；每秒校正 0.5ms，所以校正 1 秒需要 2,000 秒（約 33 分鐘） - chrony – Frequently Asked Questions chrony
建議像 makestep 1 3 這樣只在啟動後允許幾次 step；暫停後恢復的虛擬機器可能帶著錯誤的時間醒來 - clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_MONOTONIC 不受系統時鐘不連續跳動影響，也不會倒退 - chrony.conf(5) chrony
logchange：時鐘調整幅度超過這個值（預設 1 秒）時寫入 syslog
相關原因
同一層：L7 伺服器 OS（kernel）
同一症狀（快轉）在其他層的原因
查看含圖解與實驗的完整版卡片