คู่มือเกมแลค › ต้นเหตุของการส่งซ้ำใน TCP
ข้อผิดพลาดทางกายภาพ (สายเสีย/โมดูลออปติก/คอนเน็กเตอร์) Bit errors: bad cable, optics, dirty fiber
ID สาเหตุ rt-physical · ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), ภายนอก (ภายนอก)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
สายที่ชำรุด, คอนเน็กเตอร์ไฟเบอร์ที่มีฝุ่น และโมดูลออปติกที่หมดอายุการใช้งาน ทำให้เกิด bit error และอุปกรณ์จะทิ้งแพ็กเก็ตที่เสียไปเงียบ ๆ
ทำไม บิตกลับค่าเพราะสาย, โมดูลออปติก หรือคอนเน็กเตอร์เสีย → ผลคือ อุปกรณ์ทิ้งแพ็กเก็ตที่ checksum (CRC) ไม่ตรง → บนหน้าจอ เฉพาะคนที่ผ่านเส้นทางนั้นหยุดแวบสั้น ๆ แล้วกรอเร็วอยู่เป็นระยะ, ไม่ขึ้นกับช่วงเวลา
- อาการ
- ค้าง, กรอเร็ว, วาร์ป
- ปัจจัย
- แพ็กเก็ตหาย
- ใครเจอ
- บางจุด/บางแชนแนล, คนในบ้านเดียวกัน
- เกิดเมื่อไร
- ตลอดเวลา
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก อินฟราเครือข่าย (ทีมอินฟรา) · ร่วมกับ อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา), ภายนอก (ภายนอก)
- งานฝั่งทีมอินฟรา
- ตรวจทั้งสองปลายของลิงก์ (CRC error สะสมที่ฝั่งรับของทิศทางที่เสีย) เครือข่าย: ตรวจตัวนับ CRC และ input error ของพอร์ตอุปกรณ์, ตรวจความแรงสัญญาณแสง (ข้อมูลโมดูลออปติกของสวิตช์), ทำความสะอาดคอนเน็กเตอร์ไฟเบอร์, เปลี่ยนสายหรือโมดูลออปติก เครื่องเซิร์ฟเวอร์/OS: ตรวจ rx_crc_errors ใน ethtool -S ของเซิร์ฟเวอร์ (ชื่อต่างกันเล็กน้อยตามไดรเวอร์), ตรวจความแรงสัญญาณแสง (ethtool -m), เปลี่ยนสายหรือ NIC ฝั่งเซิร์ฟเวอร์
- งานฝั่งภายนอก
- ถ้าเป็นช่วงในบ้านผู้เล่น แนะนำให้เปลี่ยนสาย LAN หรือเราเตอร์, ถ้าเป็นช่วงลิงก์ของ ISP แจ้งให้ ISP ตรวจสาย
- ตัวเลขที่ควรรู้
- แพ็กเก็ตหายแค่ 0.1% ก็คือหนึ่งครั้งในแพ็กเก็ตเกม 1,000 ตัว ถ้ามีคนผ่านเส้นทางนั้นหลายสิบคน ทุกไม่กี่วินาทีจะมีใครสักคนหยุดแวบ bit error เกิดกับแพ็กเก็ตใหญ่ได้ง่ายกว่า
- บนกราฟ
- สูงเฉพาะบางกลุ่ม · จำนวน CRC error ต่อพอร์ต, อัตราการส่งซ้ำต่อเซิร์ฟเวอร์/ต่อพอร์ต
- จุดที่ต้องดู
- ตัวนับ CRC ที่ปลายทั้งสองข้างของลิงก์ เซิร์ฟเวอร์ดู rx_crc_errors ใน ethtool -S หรือ crc ใน ip -s -s link สวิตช์ดู FCS error (dot3StatsFCSErrors) และ input error (ifInErrors) ของพอร์ต ถ้าเป็นลิงก์ไฟเบอร์ ดูความแรงแสงขาเข้าจาก ethtool -m และข้อมูลโมดูลออปติกของสวิตช์
- สัญญาณว่าใช่
- CRC error ของพอร์ตหนึ่งเพิ่มขึ้นเรื่อย ๆ ไม่ขึ้นกับช่วงเวลา และอัตราการส่งซ้ำสูงเฉพาะเซิร์ฟเวอร์และการเชื่อมต่อที่ผ่านพอร์ตนั้น ความแรงแสงขาเข้าต่ำกว่าลิงก์ชนิดเดียวกันเส้นอื่น
- สัญญาณว่าไม่ใช่
- CRC ไม่ขยับแต่การทิ้งขาออกเพิ่มขึ้นอย่างเดียว: น่าจะเป็นคิวล้น (“บัฟเฟอร์ตื้นล้นเพราะ burst จากฝั่งส่ง”, “คิวคอขวดล้น”) ถ้า late collision ฝั่งหนึ่งกับ CRC อีกฝั่งเพิ่มขึ้นพร้อมกัน น่าจะเป็น “duplex ไม่ตรงกัน”
- วิธีตรวจ
- ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
แหล่งอ้างอิง
- Interface statistics Linux kernel
rx_crc_errors คือจำนวนแพ็กเก็ตที่อินเทอร์เฟซฝั่งรับนับว่าเป็น CRC error ตรวจได้ด้วย ip -s -s link และ ethtool -S - ethtool(8) — Linux manual page ethtool
-S ดูสถิติราย NIC/ไดรเวอร์, -m ดู EEPROM และข้อมูลวินิจฉัยสัญญาณแสงของโมดูลออปติก (SFP+, QSFP) - RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
FCS error (dot3StatsFCSErrors) ของพอร์ตสวิตช์ ซึ่งถูกนับรวมใน input error (ifInErrors)
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: ต้นเหตุของการส่งซ้ำใน TCP
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (ค้าง)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง