คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
duplex ไม่ตรงกัน Duplex mismatch
ID สาเหตุ rt-duplex · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าฝั่งหนึ่งใช้ auto-negotiation แต่อีกฝั่งล็อกความเร็วและ duplex ไว้ ฝั่งหนึ่งจะทำงานแบบ half duplex และทุกครั้งที่มีโหลดจะเกิด collision จนแพ็กเก็ตหาย
ทำไม ล็อกค่าความเร็วและ duplex ไว้ที่อุปกรณ์ฝั่งเดียว → ผลคือ ฝั่งหนึ่งทำงานแบบ full duplex อีกฝั่งเป็น half duplex จึงเกิด collision และ late collision → บนหน้าจอ ปกติไม่มีอาการ แต่พอทราฟฟิกเพิ่ม ทุกคนที่ผ่านอุปกรณ์นั้นค้างแล้วตามด้วยอาการกรอเร็ว
- อาการ
- ค้าง, กรอเร็ว
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- ทั้งเซิร์ฟเวอร์, บางจุด/บางแชนแนล
- เกิดเมื่อไร
- ตอนคนแห่มารวมกัน, ช่วงพีคหัวค่ำ
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
- งานฝั่งทีมอินฟรา
- ตั้งทั้งสองฝั่งเป็น auto-negotiation หรือล็อกทั้งสองฝั่งเป็นค่าเดียวกัน เครือข่าย: ดูความเร็วและ duplex จากสถานะพอร์ตสวิตช์, ดูตัวนับของพอร์ตว่าฝั่ง half duplex มี late collision เพิ่ม และฝั่ง full duplex มี CRC error และเฟรมที่สั้นเกิน (runt) เพิ่มหรือไม่ เครื่องเซิร์ฟเวอร์/OS: ตรวจความเร็วและ duplex ด้วย ethtool
- ตัวเลขที่ควรรู้
- สายทองแดง 1 Gbps ต้องใช้ auto-negotiation เสมอ และที่ 10 Gbps ขึ้นไปไม่มี half duplex เลย ปัจจุบันจึงมักเกิดกับอุปกรณ์เก่าที่ 100 Mbps หรือต่ำกว่า, พอร์ต management และบางจุดที่ต่อเข้ากับวงจรของผู้ให้บริการ
- บนกราฟ
- สูงตามจำนวนคนและโหลด · จำนวน late collision และ CRC error ของพอร์ต, อัตราการส่งซ้ำ
- จุดที่ต้องดู
- ความเร็วและ duplex จริงของทั้งสองฝั่งลิงก์ เซิร์ฟเวอร์รัน ethtool ตามด้วยชื่ออินเทอร์เฟซอย่างเดียว สวิตช์ดูสถานะพอร์ตหรือ dot3StatsDuplexStatus ใน SNMP ดู late collision (tx_window_errors ของเซิร์ฟเวอร์, dot3StatsLateCollisions ของสวิตช์) และ CRC error ไปพร้อมกัน
- สัญญาณว่าใช่
- ฝั่งหนึ่งแสดงเป็น half duplex อีกฝั่งเป็น full duplex ทุกครั้งที่ทราฟฟิกเพิ่ม ฝั่ง half duplex มี late collision และฝั่ง full duplex มี CRC error เพิ่มขึ้นพร้อมกัน
- สัญญาณว่าไม่ใช่
- ความเร็วและ duplex ทั้งสองฝั่งตรงกันแต่ CRC เพิ่มอย่างเดียว: น่าจะเป็น “ข้อผิดพลาดทางกายภาพ” ลิงก์ 10 Gbps ขึ้นไปไม่มี half duplex จึงตัดสาเหตุนี้ออก
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
มาตรฐาน 1000BASE-T กำหนดให้ต้องใช้ auto-negotiation - IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10 Gigabit Ethernet รองรับเฉพาะ full duplex - IEEE P802.3ba Objectives IEEE
40 และ 100 Gigabit Ethernet ก็รองรับเฉพาะ full duplex - Interface statistics Linux kernel
tx_window_errors คือจำนวนการส่งที่ล้มเหลวจาก late collision ส่วน rx_crc_errors คือจำนวนแพ็กเก็ตที่รับมาพร้อม CRC error - ethtool(8) — Linux manual page ethtool
ตั้งความเร็ว, duplex และ auto-negotiation ด้วย speed, duplex และ autoneg ของ ethtool -s ถ้าให้แค่ชื่ออินเทอร์เฟซจะแสดงค่าที่ตั้งอยู่ตอนนี้ - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus (แสดง duplex ปัจจุบันเป็น halfDuplex หรือ fullDuplex), dot3StatsLateCollisions (จำนวน late collision)
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง