遊戲 Lag 白皮書 › TCP 重傳的根本原因
實體層錯誤（線材、光模組、接頭不良） Bit errors: bad cable, optics, dirty fiber
原因 ID rt-physical · 主要負責 基礎設施團隊（網路基礎設施） · 協同 基礎設施團隊（伺服器基礎設施）, 外部（外部）
在含圖解與實驗的完整版中開啟卡片 →
纜線損壞、沾了灰塵的光纖接頭、壽命將盡的光模組會造成位元錯誤，損壞的封包會被設備默默丟棄。
為什麼 線材、光模組、接頭不良導致位元翻轉 → 於是 設備丟棄檢查碼（CRC）不符的封包 → 畫面上 只有經過該路徑的人持續出現短暫頓一下後快轉，與時段無關
- 症狀
- 定格, 快轉, 瞬移
- 因素
- 遺失
- 誰會遇到
- 特定地點／頻道, 同一個家
- 何時
- 一直都有
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 基礎設施團隊（伺服器基礎設施）, 外部（外部）
- 基礎設施團隊要做的事
- CRC 錯誤會累積在出錯方向的接收端，所以兩端都要檢查。網路：檢查設備 port 的 CRC 與輸入錯誤計數器、檢查光訊號強度（交換器的光模組資訊）、清潔光纖接頭、更換線材與光模組。伺服器設備／OS：檢查伺服器 ethtool -S 的 rx_crc_errors（名稱依驅動程式略有不同）、檢查光訊號強度（ethtool -m）、更換伺服器端的線材或 NIC。
- 外部要做的事
- 問題在玩家家中時，建議更換網路線或分享器；問題在電信業者線路區段時，請電信業者檢修線路。
- 數值參考
- 即使只有 0.1% 的遺失，也等於每 1,000 個遊戲封包遺失一次。經過該路徑的人有數十人時，每隔幾秒就有人頓一下。封包越大越容易遇上位元錯誤。
- 圖表上
- 只有部分偏高 · 各 port 的 CRC 錯誤數、各伺服器／port 的重傳率
- 查看位置
- 查看鏈路兩端的 CRC 計數器。伺服器看 ethtool -S 的 rx_crc_errors 或 ip -s -s link 的 crc，交換器看 port 的 FCS 錯誤（dot3StatsFCSErrors）與輸入錯誤（ifInErrors）。光纖鏈路則用 ethtool -m 與交換器的光模組資訊查看接收光功率
- 符合的跡象
- 某個 port 的 CRC 錯誤不分時段持續增加，只有經過該 port 的伺服器與連線重傳率偏高。接收光功率比同類型的其他鏈路低
- 不符合的跡象
- CRC 沒有變化、只有輸出丟棄增加時是佇列溢位（「突發傳送造成淺緩衝區溢位」、「瓶頸佇列溢位」）。一端的延遲碰撞（late collision）與另一端的 CRC 一起增加時是「雙工模式不一致」
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Interface statistics Linux kernel
rx_crc_errors 是接收端介面判定為 CRC 錯誤的封包數，可用 ip -s -s link 與 ethtool -S 確認 - ethtool(8) — Linux manual page ethtool
-S 查看 NIC 與驅動程式的統計，-m 查看光模組（SFP+、QSFP）的 EEPROM 與光學診斷資訊 - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
交換器 port 的 FCS 錯誤（dot3StatsFCSErrors），此錯誤會一併計入輸入錯誤（ifInErrors）
相關原因
同一層：TCP 重傳的根本原因
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片