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

ความละเอียดของตัวจับเวลา Timer resolution (Windows 15.6ms)

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

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

ตัวจับเวลาเริ่มต้นของ Windows ทำงานเป็นหน่วย 15.6 ms การ “พักแค่ 1 ms” จึงกลายเป็นการรอจนถึงรอบตัวจับเวลาถัดไป นานสุดถึง 15.6 ms

ทำไม เขียนการจำกัดเฟรมและการส่งแพ็กเก็ตด้วยวิธี Sleep (รอสักครู่) → ผลคือ OS ปลุกให้ได้เป็นหน่วย 15.6 ms เท่านั้น → บนหน้าจอ ช่วงห่างระหว่างเฟรมและช่วงห่างการส่งอินพุตไม่สม่ำเสมอ

อาการ

กระตุก

ปัจจัย

จิตเตอร์

ใครเจอ

เราคนเดียว

เกิดเมื่อไร

ตลอดเวลา

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

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

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

ใช้ high-resolution timer, ทำ pacing ด้วย event หรือ V-Sync แทนการรอ

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

หน่วย 15.6 ms ทำให้ได้ช่วงห่าง 16.7 ms พอดีไม่ได้ ช่วงห่างระหว่างเฟรมจึงสลับไปมาระหว่าง 15.6 ms กับ 31.2 ms

บนกราฟ

สูงตลอดตั้งแต่แรก · การกระจายของช่วงห่างระหว่างเฟรม

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

ดูการกระจายของ MsBetweenPresents (ช่วงห่างระหว่างเฟรม) จาก PresentMon และหัวข้อ “Platform Timer Resolution” ในรายงาน powercfg /energy (โปรเซสที่เปลี่ยนความละเอียดของตัวจับเวลา)

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

ช่วงห่างระหว่างเฟรมกระจุกอยู่ที่ผลคูณของ 15.6 ms เช่น 15.6 ms และ 31.2 ms และเกมไม่ได้ขอความละเอียดของตัวจับเวลาที่สูงขึ้น

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

ช่วงห่างกระจายไปทั่ว ไม่กระจุกที่ค่าใดค่าหนึ่ง: น่าจะเป็น “โปรเซสเบื้องหลังแย่ง CPU” หรือภาระของเฟรม มากกว่าตัวจับเวลา

วิธีตรวจ

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

รายละเอียดเพิ่มเติม

ใน Windows รุ่นเก่า ถ้าโปรแกรมหนึ่งเปลี่ยนตัวจับเวลาเป็น 1 ms จะมีผลกับทุกโปรแกรม จึงเคยมีคำพูดว่า “เปิดเบราว์เซอร์ทิ้งไว้แล้วเกมลื่นขึ้น” ตั้งแต่ Windows 10 เวอร์ชัน 2004 จะมีผลเฉพาะโปรแกรมที่ร้องขอ และ Windows 11 อาจไม่ใช้คำขอของหน้าต่างที่ถูกย่อหรือถูกบังจนมองไม่เห็นและไม่มีเสียง

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

1. _WDF_TIMER_CONFIG (wdftimer.h) Microsoft
   ความแม่นยำของตัวจับเวลาทั่วไปคือช่วงห่างของ system clock tick ค่าเริ่มต้น 15.6 ms ส่วน high-resolution timer คือ 1 ms
2. timeBeginPeriod function (timeapi.h) Microsoft
   ก่อน Windows 10 เวอร์ชัน 2004 เป็นการตั้งค่าทั้งระบบ หลังจากนั้นมีผลเฉพาะโปรเซสที่ร้องขอ Windows 11 ไม่รับประกันความละเอียดสูงให้โปรเซสของหน้าต่างที่ถูกบังหรือถูกย่อ
3. CreateWaitableTimerExW function (synchapi.h) Microsoft
   แฟล็กของ high-resolution waitable timer: CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
4. PresentMon Capture Application (README-CaptureApplication.md) Intel
   MsBetweenPresents: เวลาระหว่างการเรียก Present() ครั้งนี้กับครั้งก่อน (ms)
5. Results for the Idle Energy Efficiency Assessment Microsoft
   ความละเอียดของ system timer ค่าเริ่มต้น 15.6 ms หาโปรเซสที่เปลี่ยนความละเอียดของตัวจับเวลาได้จากหัวข้อ “Platform Timer Resolution” ในรายงานพลังงาน
6. Powercfg command-line options Microsoft
   powercfg /energy: วิเคราะห์ระบบแล้วสร้างรายงานพลังงาน (HTML)

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

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

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

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

• เฟรมไทม์พุ่ง L1 โปรเซสเกมฝั่งไคลเอนต์
• GC ฝั่งไคลเอนต์ L1 โปรเซสเกมฝั่งไคลเอนต์
• โหลดแบบ synchronous และคอมไพล์ shader บนเมนเธรด L1 โปรเซสเกมฝั่งไคลเอนต์
• สตอเรจช้าจนสตรีมแอสเซ็ตไม่ทัน L1 โปรเซสเกมฝั่งไคลเอนต์
• ภาระการเรนเดอร์ตัวละครจำนวนมาก L1 โปรเซสเกมฝั่งไคลเอนต์
• ไม่มี interpolation buffer หรือสั้นเกินไป L1 โปรเซสเกมฝั่งไคลเอนต์
• extrapolation มากเกินไป (dead reckoning) L1 โปรเซสเกมฝั่งไคลเอนต์
• fixed timestep ไล่ตามไม่ทันจนบานปลาย L1 โปรเซสเกมฝั่งไคลเอนต์

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