ゲームラグ白書 › TCP再送の根本原因
デュプレックスの不一致 Duplex mismatch
原因ID rt-duplex · 主担当 インフラチーム・ネットワークインフラ · 副担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
片側はオートネゴシエーション、もう片側は速度・デュプレックスを固定にしておくと、片側が半二重で動作し、負荷がかかるたびに衝突（コリジョン）でパケットを失います。
なぜ 機器の片側だけ速度・デュプレックスを固定設定 → すると 片側は全二重、もう片側は半二重で動作し、コリジョン・レイトコリジョンが発生 → 画面では 普段は問題ないが、トラフィックが増えるとその機器を通る人全員が止まっては早送り
- 症状
- フリーズ, 早送り
- 要因
- パケットロス
- 誰に起きるか
- サーバー全体, 特定の場所・チャンネル
- いつ
- 人が集中したとき, 夜のピーク時間帯
- 担当
- 主担当 インフラチーム・ネットワークインフラ · 副担当 インフラチーム・サーバーインフラ
- インフラチームの対応
- 両側ともオートネゴシエーション、または両側とも同じ値で固定。ネットワーク：スイッチポートの状態で速度・デュプレックスを確認、ポートカウンターで半二重側はレイトコリジョン、全二重側はCRCエラー・短すぎるフレーム（runt）が増えていないか確認。サーバー機器・OS：ethtoolで速度・デュプレックスを確認。
- 数値の目安
- 1Gbpsの銅線ケーブルはオートネゴシエーションが必須で、10Gbps以上には半二重そのものがありません。そのため最近は主に、100Mbps以下の古い機器、管理用ポート、一部の回線の接続区間で起きます。
- グラフでは
- 人数・負荷に連動して上昇 · ポートのレイトコリジョン・CRCエラー数、再送率
- 確認箇所
- リンク両側の実際の速度・デュプレックスを確認。サーバーはインターフェース名だけを付けて実行したethtool、スイッチはポートの状態や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ギガビットイーサネットは全二重のみをサポート - IEEE P802.3ba Objectives IEEE
40・100ギガビットイーサネットも全二重のみをサポート - 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再送の根本原因
同じ症状（フリーズ）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る