遊戲 Lag 白皮書 › TCP 重傳的根本原因
雙工模式不一致 Duplex mismatch
原因 ID rt-duplex · 主要負責 基礎設施團隊（網路基礎設施） · 協同 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
一端設為自動協商、另一端把速度與雙工固定時，其中一端會以半雙工運作，每當負載升高就因碰撞而遺失封包。
為什麼 只有其中一台設備把速度與雙工設成固定值 → 於是 一端以全雙工運作、另一端以半雙工運作，發生碰撞與延遲碰撞 → 畫面上 平常一切正常，流量一增加，經過該設備的所有人都會定格後快轉
- 症狀
- 定格, 快轉
- 因素
- 遺失
- 誰會遇到
- 整個伺服器, 特定地點／頻道
- 何時
- 人潮湧入時, 晚間尖峰時段
- 負責單位
- 主要負責 基礎設施團隊（網路基礎設施） · 協同 基礎設施團隊（伺服器基礎設施）
- 基礎設施團隊要做的事
- 兩端都設為自動協商，或兩端都固定為相同的值。網路：在交換器 port 狀態中確認速度與雙工，並在 port 計數器中確認半雙工那一端的延遲碰撞、全雙工那一端的 CRC 錯誤與過短訊框（runt）是否增加。伺服器設備／OS：用 ethtool 確認速度與雙工。
- 數值參考
- 1Gbps 銅線必須使用自動協商，10Gbps 以上則根本沒有半雙工。所以現在主要發生在 100Mbps 以下的老舊設備、管理用 port，以及部分線路介接區段。
- 圖表上
- 隨人數／負載上升 · port 延遲碰撞與 CRC 錯誤數、重傳率
- 查看位置
- 查看鏈路兩端實際的速度與雙工。伺服器用只加介面名稱執行的 ethtool，交換器看 port 狀態或 SNMP 的 dot3StatsDuplexStatus。同時查看延遲碰撞（伺服器 tx_window_errors、交換器 dot3StatsLateCollisions）與 CRC 錯誤
- 符合的跡象
- 一端顯示半雙工，另一端顯示全雙工。每當流量增加，半雙工那一端的延遲碰撞與全雙工那一端的 CRC 錯誤就一起增加
- 不符合的跡象
- 兩端速度與雙工相同、只有 CRC 增加時是「實體層錯誤」。10Gbps 以上的鏈路沒有半雙工，可排除這個原因
- 確認方式
- 用基礎設施工具確認（不需要遊戲程式碼）
出處
- Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
1000BASE-T 規格要求自動協商 - IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10 Gigabit 乙太網路只支援全雙工 - IEEE P802.3ba Objectives IEEE
40 與 100 Gigabit 乙太網路也只支援全雙工 - Interface statistics Linux kernel
tx_window_errors 是因延遲碰撞（late collision）而失敗的傳送次數，rx_crc_errors 是收到的 CRC 錯誤封包數 - ethtool(8) — Linux manual page ethtool
用 ethtool -s 的 speed、duplex、autoneg 設定速度、雙工與自動協商；只給介面名稱時會顯示目前設定 - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus（以 halfDuplex、fullDuplex 顯示目前的雙工模式）、dot3StatsLateCollisions（延遲碰撞次數）
相關原因
同一層：TCP 重傳的根本原因
同一症狀（定格）在其他層的原因
查看含圖解與實驗的完整版卡片