คู่มือเกมแลค › L2 OS และอุปกรณ์ฝั่งไคลเอนต์

receive buffer ล้น Socket receive buffer overflow

ID สาเหตุ co-rcvbuf · ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)

เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →

ถ้าเกมยุ่งจนดึงแพ็กเก็ตออกจากซ็อกเก็ต (อินเทอร์เฟซรับส่งข้อมูลเครือข่ายที่ OS จัดให้) ช้า บัฟเฟอร์ของ OS จะล้น

ทำไม เฟรมช้าจนเกมอ่านซ็อกเก็ตไม่ทัน → ผลคือ receive buffer ของ OS เต็ม UDP จะถูกทิ้ง ส่วน TCP จะลด receive window ให้ฝั่งส่งหยุดส่ง → บนหน้าจอ วาร์ป (UDP) หรือกรอเร็ว (TCP)

อาการ

วาร์ป, กรอเร็ว

ปัจจัย

แพ็กเก็ตหาย, การหยุดชะงัก

ใครเจอ

เราคนเดียว

เกิดเมื่อไร

ตอนคนแห่มารวมกัน

ผู้รับผิดชอบ

ผู้รับผิดชอบหลัก พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)

งานฝั่งทีมพัฒนาเกม

แยกเธรดสำหรับรับข้อมูลโดยเฉพาะ, ปรับขนาดบัฟเฟอร์ (SO_RCVBUF)

ตัวเลขที่ควรรู้

receive buffer เริ่มต้นมีขนาดหลายสิบถึงหลายร้อย KB ขึ้นกับ OS และการตั้งค่า อัปเดตในที่ที่คนเยอะอาจสูงถึงหลายร้อย KB ใน 1 วินาที

บนกราฟ

สูงตามจำนวนคนและโหลด · จำนวน UDP ที่ถูกทิ้งที่ receive buffer, เฟรมไทม์

จุดที่ต้องดู

บันทึก Microsoft Winsock BSP\Dropped Datagrams (จำนวน UDP ที่ถูกทิ้งเพราะ receive buffer ของซ็อกเก็ตไม่พอ) และ UDPv4\Datagrams Received Errors ใน Performance Monitor ของ Windows คู่กับเฟรมไทม์ ฝั่งเกมนับช่องว่างของหมายเลขลำดับแพ็กเก็ตที่ได้รับ

สัญญาณว่าใช่

ในที่ที่คนเยอะหรือทันทีหลังเฟรมยาว Dropped Datagrams เพิ่มขึ้น และในจังหวะเดียวกันหมายเลขลำดับในเกมมีช่องว่าง ขณะที่ช่วงเวลาเดียวกันไม่มีแพ็กเก็ตหายฝั่งเน็ต

สัญญาณว่าไม่ใช่

Dropped Datagrams เท่าเดิมแต่หมายเลขลำดับขาดหาย: แพ็กเก็ตหายระหว่างทาง

วิธีตรวจ

ตรวจที่สภาพแวดล้อมฝั่งผู้เล่น

แหล่งอ้างอิง

1. socket(7) — Linux manual page Linux man-pages
   SO_RCVBUF คือขนาดสูงสุดของ receive buffer ของซ็อกเก็ต ค่าเริ่มต้นกำหนดโดย rmem_default และค่าสูงสุดโดย rmem_max (Android ก็ใช้เคอร์เนล Linux)
2. SOL_SOCKET Socket Options (Winsock2.h) Microsoft
   SO_RCVBUF ของ Windows: พื้นที่บัฟเฟอร์ที่จองไว้สำหรับรับข้อมูลในแต่ละซ็อกเก็ต
3. RFC 9293: Transmission Control Protocol (TCP) IETF
   ฟิลด์ window ของ TCP คือจำนวนไบต์ที่ฝั่งรับยังรับเพิ่มได้ ถ้าเป็น 0 ฝั่งส่งจะส่งแค่ zero window probe และรอ
4. Low Latency Workloads Management and Operations Microsoft
   Dropped Datagrams และ Dropped Datagrams/sec ในชุดตัวนับ Microsoft Winsock BSP: จำนวน UDP ที่ถูกทิ้งเพราะมาเร็วกว่าที่แอปประมวลผลทัน หรือ receive buffer ของซ็อกเก็ตไม่พอ
5. Network-Related Performance Counters Microsoft
   ตัวนับ UDPv4/UDPv6: Datagrams Received Errors และ Microsoft Winsock BSP: Dropped Datagrams

สาเหตุที่ควรดูประกอบ

ชั้นเดียวกัน: L2 OS และอุปกรณ์ฝั่งไคลเอนต์

• โปรเซสเบื้องหลังแย่ง CPU
• โหมดประหยัดพลังงานและ thermal throttling
• ความละเอียดของตัวจับเวลา
• สลับแอปมือถือไปเบื้องหลัง
• สลับ Wi-Fi ↔ LTE/5G
• โปรแกรมความปลอดภัยตรวจแพ็กเก็ต
• หน่วยความจำฝั่งไคลเอนต์ไม่พอและ swap
• หน่วยความจำกราฟิก (VRAM) ไม่พอ
• การสแกน Wi-Fi เบื้องหลัง
• โหมดประหยัดพลังงานของ NIC และปัญหาไดรเวอร์
• แอปอื่นในเครื่องเดียวกันแย่งแบนด์วิดท์
• จำกัดการประมวลผลเมื่อย่อหรือสลับหน้าต่าง
• โปรแกรมโอเวอร์เลย์รบกวน
• ดีเลย์จากจอ, อุปกรณ์อินพุต และ frame generation

สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (วาร์ป)

• extrapolation มากเกินไป (dead reckoning) L1 โปรเซสเกมฝั่งไคลเอนต์
• Wi-Fi ถูกรบกวนหรือสัญญาณอ่อน L3 เครือข่ายในบ้าน
• bufferbloat (คิวในเราเตอร์) L3 เครือข่ายในบ้าน
• handover ระหว่างเสาสัญญาณ (ขณะเดินทาง) L3 เครือข่ายในบ้าน
• สัญญาณมือถืออ่อนหรืออยู่ในจุดอับสัญญาณ L3 เครือข่ายในบ้าน
• สลับ 5G↔LTE บ่อย (บริเวณขอบพื้นที่ 5G) L3 เครือข่ายในบ้าน
• อินเทอร์เน็ตดาวเทียม (วงโคจรต่ำ/ค้างฟ้า) L4 เส้นทางอินเทอร์เน็ต
• จุด peering แออัดช่วงพีค L4 เส้นทางอินเทอร์เน็ต

ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง