Polling Rate: 1000Hz ดีกว่า 500Hz ไหม?

การเพิ่ม polling rate จาก 500Hz เป็น 1000Hz ลดช่วงรายงานจากสองมิลลิวินาทีเหลือหนึ่ง ให้การปรับปรุงหนึ่งมิลลิวินาทีในขั้นตอนเดียวของห่วงโซ่ latency ที่ยาวกว่ามาก ในทางปฏิบัติผลกำไรนั้นมองไม่เห็นเมื่อเทียบกับ refresh interval ของจอ เวลาเฟรมของ GPU และความเร็วปฏิกิริยาของมนุษย์ ซึ่งทั้งหมดใหญ่กว่าเป็นอันดับของขนาด polling rate ที่สูงขึ้นช่วยได้ก็ต่อเมื่อทุกลิงก์อื่นเร็วแล้ว หมายถึงจอ refresh สูง เฟรมเรตสูงอย่างต่อเนื่อง และ latency ระบบต่ำทั่วทั้งสาย สำหรับงานออฟฟิศและเกมทั่วไป 500Hz เหมือนกันจริงๆ ในขณะที่ใช้เวลาโปรเซสเซอร์น้อยกว่าและแบตเตอรี่น้อยกว่าบนอุปกรณ์ไร้สาย — แม้ตัวรับสัญญาณ 2.4GHz สมัยใหม่รองรับ 1000Hz เมื่อคุณต้องการ

ตามตัวเลข

การกระโดดจาก 125Hz เป็น 1000Hz ตัดการรอเฉลี่ย 3.5ms การกระโดดจาก 1000Hz เป็น 8000Hz ตัดประมาณ 0.44ms นี่คือความแตกต่างของขั้นตอน polling ที่คำนวณได้ ไม่ใช่การวัดจากต้นทางถึงปลายทางของเมาส์หรือระบบใดระบบหนึ่ง

ผู้ผลิตเมาส์โฆษณา polling 8000Hz เป็นสเปกหัวเรื่อง พร้อมนัยชัดเจนว่าต่ำกว่านั้นกำลังถ่วงคุณไว้ การเปลี่ยนจาก 500Hz เป็น 1000Hz จริงจริงบนกระดาษ แต่ผลบนจอน้อยกว่าที่ตัวเลขเพิ่มสองเท่าบอกมาก และการไล่อัตราที่สูงขึ้นมีต้นทุนที่เอกสารการตลาดไม่กล่าวถึง นี่คือการบัญชีที่ตรงไปตรงมา

polling rate อธิบายอะไรจริงๆ

เมาส์ของคุณสุ่มตำแหน่งและส่งข้อมูลนั้นให้คอมพิวเตอร์ที่ความถี่คงที่ ที่ 500Hz รายงานทุกสองมิลลิวินาที ที่ 1000Hz ทุกหนึ่งมิลลิวินาที ที่ 8000Hz ทุก 0.125 มิลลิวินาที อัตราที่สูงขึ้นหมายถึงการอัปเดตตำแหน่งบ่อยขึ้น และดังนั้นอาจมี delay น้อยลงระหว่างมือเคลื่อนกับเคอร์เซอร์ตอบสนอง

คำสำคัญคือ อาจ Polling เป็นขั้นตอนหนึ่งในไปป์ไลน์ latency และมันไม่ค่อยเป็นขั้นตอนที่ยาวที่สุด

คณิตศาสตร์ที่ทุกคนอ้าง และบริบทที่มันลืม

ความแตกต่างระหว่าง 1000Hz กับ 500Hz คือ หนึ่งมิลลิวินาที ในช่วงรายงาน นั่นคือผลกำไรที่วัดได้ทั้งหมดที่ขั้นตอน polling และเนื่องจากการเคลื่อนไหวเกิดที่จุดสุ่มในช่วง การประหยัดเฉลี่ยที่เกิดจริงใกล้ครึ่งมิลลิวินาที

ตอนนี้วางมันข้างขั้นตอนอื่นของไปป์ไลน์เดียวกัน:

หนึ่งมิลลิวินาทีที่ได้จากการเพิ่ม polling rate เป็นแค่ error จากการปัดทศนิยมเทียบกับ refresh จอและการเรนเดอร์เฟรม และเล็กกว่าเวลาปฏิกิริยาของคุณเองราวสองร้อยเท่า ความสัมพันธ์ตามสัดส่วนนี้คือเหตุผลทั้งหมดที่ผู้เล่นส่วนใหญ่แยก 500Hz จาก 1000Hz ในการเปรียบเทียบแบบไม่บอกยี่ห้อไม่ได้จริงๆ ไม่ว่าพวกเขาจะคาดหวังจะรู้สึกอะไร

เมื่อ 1000Hz ขึ้นไปช่วยจริงๆ

Polling ที่สูงกว่าก่อผลกำไรก็ต่อเมื่อ ทุกลิงก์อื่นในห่วงโซ่เร็วแล้ว โดยเฉพาะต้องการ:

• จอ refresh สูง ในช่วง 240Hz ถึง 360Hz เพื่อจอสามารถนำเสนออัปเดตที่ช่วงต่ำกว่าสี่มิลลิวินาทีได้จริง
• เฟรมเรตสูงอย่างต่อเนื่อง สูงกว่าสามร้อยอย่างมีนัย เพื่อเฟรมที่เรนเดอร์แล้วจะมีเติมโอกาส refresh เหล่านั้น
• latency ระบบต่ำทั่วทั้งสาย รวมการเชื่อมต่อ USB ตรง การประมวลผลพื้นหลังน้อย และไม่มี overlay ในเส้นทางอินพุต

ภายในหน้าต่างการแข่งขันที่ปรับให้เหมาะสมโดยตั้งใจแคบนั้น ผู้เล่นจำนวนน้อยสามารถสกัดค่าจริงจาก 1000Hz และบางครั้งจากอัตราที่สูงกว่า นอกนั้นผลกำไรพังทลายเป็นสิ่งที่มองไม่เห็น เพราะคอขวดย้ายไปที่อื่นและรายงานเพิ่มเติมถูกรวมหรือสุ่มตัวอย่างก่อนมีอิทธิพลต่อสิ่งที่มองเห็น

ต้นทุนของการเพิ่มต่อไป

Polling ที่สูงขึ้นไม่ฟรี และเหนือ 1000Hz การแลกกลายเป็นมีนัย:

โหลดโปรเซสเซอร์

ทุกรายงานผ่าน input stack ของระบบปฏิบัติการและมักรวมเอนจินเกม ที่สี่พันถึงแปดพันเฮิรตซ์นี่กินเวลาโปรเซสเซอร์ที่วัดได้ และบนระบบที่อ่อนกว่าการลดเฟรมเรตที่เกิดขึ้นสามารถเพิ่ม latency รวมแทนที่จะลด

การใช้แบตเตอรี่

เมาส์ไร้สายใช้พลังงานมากขึ้นอย่างมากที่อัตราสูง และ 8000Hz สามารถลดเวลาใช้งานระหว่างชาร์จอย่างมาก

รายงานที่แทบไม่เคยแปลเป็นประโยชน์ที่มองเห็นได้

เมาส์ 8000Hz รายงานทุก 0.125 มิลลิวินาที ในขณะที่จอ 360Hz รีเฟรชทุก 2.8 มากกว่ายี่สิบรายงานมาระหว่างเฟรมติดต่อกัน และ granularity พิเศษไม่มีจุดหมาย

Polling rate ไม่ใช่คุณภาพการเล็งหรือ DPI

ความสับสนสองอย่างที่คงอยู่บิดเบือนการตัดสินใจซื้อ:

• DPI คือความไวของเซนเซอร์ อธิบายการเคลื่อนที่ของเคอร์เซอร์ต่อนิ้วของการเคลื่อนเมาส์ทางกายภาพ เป็นอิสระจาก polling โดยสิ้นเชิงและปรับเพื่อความสบายไม่ใช่ latency
• คุณภาพการเล็ง มาจากความแม่นยำของเซนเซอร์ พื้นผิว การจับ และการฝึก เมาส์ 1000Hz กับเซนเซอร์ที่มี smoothing หรือ angle snapping จะเล็งแย่กว่าเมาส์ 500Hz กับเซนเซอร์สะอาด

ทั้งสองไม่ถูกปรับปรุงด้วยสเปก polling และผู้ผลิตได้ประโยชน์จากความคลุมเครือ

ยืนยันสิ่งที่คุณได้รับจริง

อัตราที่กำหนดค่ากับอัตราที่ส่งสามารถแตกต่างกันได้ แต่เบราว์เซอร์ไม่สามารถอ่านอัตรา polling rate ของฮาร์ดแวร์ได้โดยตรง: เหตุการณ์เมาส์ขึ้นอยู่กับการรวมของเบราว์เซอร์ การจัดตารางเธรดหลัก และการจัดการอินพุตของ OS ดังนั้นการจับเวลาบนเว็บไม่สามารถพิสูจน์ช่วงรายงาน USB จริงได้ สำหรับการวัดที่เชื่อถือได้ ให้ใช้ยูทิลิตีเนทีฟเฉพาะที่อ่านข้อมูลระดับ USB หรือซอฟต์แวร์ผู้ผลิตเมาส์ของคุณ สิ่งที่เครื่องมือเบราว์เซอร์เช่น mouse tester ของเราสามารถช่วยได้คือการตรวจสอบรูปแบบคร่าว ๆ — ช่องว่างที่ยาวและสม่ำเสมอผิดปกติระหว่างการอัปเดตที่บันทึกไว้สามารถบ่งชี้ว่าเส้นทางการเชื่อมต่อ (ฮับที่ใช้ร่วมกัน หัวหน้าพาเนล หรือสายที่ไม่ดี) กำลังจำกัดการส่งมอบ ซึ่งควรตรวจสอบด้วยเครื่องมือเนทีฟ เสียบตรงกับพอร์ต USB 3.0 ด้านหลังเมนบอร์ดและทดสอบใหม่ก่อนสรุปว่าเมาส์เสีย

ค่าเริ่มต้นที่แนะนำ

• เมาส์เกมมิ่งมีสาย: 1000Hz ปลอดภัย มาตรฐาน ไม่มีข้อเสียที่มีนัย
• เมาส์ไร้สาย: ตัวรับสัญญาณ 2.4GHz สมัยใหม่รองรับ 1000Hz ดังนั้นเลือกตามลำดับความสำคัญ: 1000Hz หากต้องการการตอบสนองสูงสุด หรือ 500Hz หากอายุแบตเตอรี่สำคัญกว่า — ความแตกต่างในความรู้สึกไม่สามารถรับรู้ได้สำหรับผู้ใช้ส่วนใหญ่ และการประหยัดแบตเตอรี่ที่ 500Hz เป็นจริง
• เครื่องแข่งขันกับจอ refresh สูงและเฟรมเรตสูง: ลอง 1000Hz ถึง 2000Hz และประเมินตรงๆ ว่า คุณ ตรวจจับความแตกต่างได้ไหม ถ้าไม่ ถอยลงแล้วเรียกพื้นที่โปรเซสเซอร์คืน
• คนอื่นทุกคน รวมการใช้งานผลิตภาพทั้งหมด: 500Hz เพียงพอทั้งหมด คำถามนี้ไม่สมควรใส่ใจต่อ

วิธีที่ USB จัดการรายงานเมาส์ที่ระดับโปรโตคอล

การเข้าใจสิ่งที่เกิดขึ้นเมื่อเมาส์รายงานตำแหน่งช่วยอธิบายทำไม polling rate จึงมีลักษณะที่เป็นอยู่ และทำไมความสัมพันธ์ระหว่างสเปกกับผลจริงไม่ตรงไปตรงมาอย่างที่การตลาดชี้นำ

อุปกรณ์ USB สื่อสารกับ host ผ่าน endpoint แต่ละอันกำหนดค่าสำหรับประเภท transfer เฉพาะ เมาส์ใช้ interrupt transfer ซึ่ง host controller จัดตารางช่วง polling ตามความถี่ที่กำหนดค่า — host จองสล็อตเวลาเหล่านั้น แม้การส่งจริงอาจยังสะดุด (jitter) ภายใต้โหลดของระบบ ที่ 1000Hz host controller จัดสล็อต microframe หนึ่งมิลลิวินาทีให้ interrupt endpoint ของเมาส์ และเมาส์วาง packet รายงานลงในสล็อตนั้นประกอบด้วย position delta ปัจจุบัน สถานะปุ่ม และข้อมูลเซนเซอร์เพิ่มเติม

packet รายงานเองถูกกำหนดโดย HID descriptor ของอุปกรณ์ ซึ่งประกาศโครงสร้างและขนาดของข้อมูลที่เมาส์ส่ง รายงานมาตรฐานประกอบด้วย byte สถานะปุ่ม X delta Y delta และตัวเลือกล้อและข้อมูลแกนเพิ่มเติม payload รวมเล็ก — มัก 8 ถึง 16 byte — ซึ่งหมายความว่าแบนด์วิดท์แทบไม่เคยเป็นข้อจำกัด ข้อจำกัดคือ timing: host จัดตาราง transfer บ่อยแค่ไหน อุปกรณ์เติมได้เร็วแค่ไหน และ input stack ของระบบปฏิบัติการประมวลผลได้เร็วแค่ไหน

ที่ระดับระบบปฏิบัติการ แต่ละรายงานที่ได้รับทริกเกอร์ interrupt ที่แพร่ผ่าน USB driver stack, HID class driver และในที่สุด input subsystem ซึ่งอัปเดตตำแหน่งเคอร์เซอร์หรือส่งต่อเหตุการณ์ให้แอปพลิเคชันเบื้องหน้า แต่ละชั้นเพิ่มเวลาประมวลผลเล็กน้อย และที่ 8000Hz ชั้นเหล่านี้กินรอบ CPU ที่วัดได้ร่วมกัน — เหตุผลที่ polling rate สูงสุดสามารถลดประสิทธิภาพเกมบนโปรเซสเซอร์ที่อ่อนกว่า ระบบปฏิบัติการไม่ได้ส่งต่อทุกรายงานให้เอนจินเกมอย่างง่ายๆ มัน batch รวม หรือประมวลผลตามดีไซน์การจัดการอินพุตของตัวเอง ซึ่งหมายความว่าไม่ใช่ทุกรายงานที่จำเป็นต้องมีอิทธิพลต่อเฟรมที่เรนเดอร์

ความเข้าใจระดับโปรโตคอลนี้ชี้แจงหลายประเด็น หนึ่ง polling rate เป็นคุณสมบัติของการกำหนดค่า USB endpoint ไม่ใช่ของเซนเซอร์เมาส์ — เซนเซอร์สุ่มที่อัตราของตัวเองอิสระ สอง host และอุปกรณ์ที่เข้ากันได้สามารถจัดตารางรายงานตามช่วงที่กำหนดค่าไว้ แต่จังหวะจริงยังขึ้นกับ descriptor, เฟิร์มแวร์, การเชื่อมต่อ และการจัดตารางของระบบปฏิบัติการ สาม ต้นทุนการประมวลผลจริงและสะสมที่อัตราสูงสุด ซึ่งเป็นเหตุผลที่เมาส์ 8000Hz สามารถลดประสิทธิภาพเกมแทนที่จะปรับปรุง สเปกอธิบายจังหวะการจัดตาราง ไม่ใช่การรับประกันการปรับปรุงการรับรู้ และชั้นระหว่างสายกับจอแต่ละชั้นแนะนำ latency ของตัวเองที่ polling rate ไม่สามารถจัดการได้

ความซับซ้อนเพิ่มเติมคือการจัดตาราง USB controller ไม่ได้กำหนดได้สมบูรณ์ host controller จัดการอุปกรณ์หลายตัวที่แชร์บัสเดียวกัน และแม้ interrupt transfer รับประกันสล็อต แต่ traffic อื่นบน controller เดียวกันสามารถก่อ jitter — ความแปรผันเล็กๆ ในจังหวะเวลาที่ transfer แต่ละครั้งเกิด บนระบบที่กำหนดค่าดีที่เมาส์อยู่บน controller เฉพาะ jitter นี้น้อยมาก มักต่ำกว่า 0.1 มิลลิวินาที บนระบบที่เมาส์แชร์ controller กับอุปกรณ์แบนด์วิดท์สูงเช่น external storage หรือ capture card การแย่งการจัดตารางสามารถก่อ delay บางครั้งที่เล็กในเทอมสัมบูรณ์แต่วัดได้ด้วยเครื่องมือจับเวลาที่แม่นยำ นี่เป็นเหตุผลหนึ่งที่ผู้เล่นแข่งขันมักเสียบเมาส์ไปยังพอร์ต USB เฉพาะที่ผู้ผลิตเมนบอร์ดแนะนำ แทนพอร์ตที่ใกล้ที่สุด

เพื่อเข้าใจว่า polling rate อยู่ที่ไหนในห่วงโซ่ latency โดยรวม ช่วยให้ติดตามการเคลื่อนเมาส์ครั้งเดียวผ่านทุกขั้นตอนจากพื้นผิวทางกายภาพถึงการเปลี่ยนเคอร์เซอร์ที่มองเห็น แต่ละขั้นตอนก่อเวลา และ polling เป็นเพียงหนึ่งในนั้น

การสุ่มเซนเซอร์ เซนเซอร์ออปติคอลในเมาส์ของคุณจับภาพพื้นผิวที่อัตราภายในสูง — มัก 12,000 ถึง 16,000 เฟรมต่อวินาที — และเปรียบเทียบเฟรมติดต่อกันเพื่อคำนวณการเคลื่อนไหว กระบวนการนี้เป็นภายในเซนเซอร์ทั้งหมดและทำงานที่ความถี่ของตัวเอง อิสระจาก USB polling rate เซนเซอร์ผลิต position delta และส่งให้ microcontroller ของเมาส์

การประมวลผล microcontroller MCU รับ sensor delta ใช้การประมวลผลที่กำหนดค่าไว้เช่น angle snapping, smoothing หรือ acceleration และประกอบเป็น USB report packet ขั้นตอนนี้เพิ่ม delay เล็กน้อยแต่ไม่เป็นศูนย์ มักต่ำกว่าหนึ่งมิลลิวินาทีบนเฟิร์มแวร์ที่วิศวกรรมดี แต่อาจยาวกว่าบนอุปกรณ์ที่มี DSP processing หนัก

การ transfer USB นี่คือขั้นตอนที่ polling rate ควบคุม ที่ 1000Hz report ที่ประกอบแล้วรอ interrupt transfer ที่จัดตารางถัดไป ซึ่งเกิดทุกหนึ่งมิลลิวินาที โดยเฉลี่ย report รอครึ่งช่วงเวลานั้น — 0.5 มิลลิวินาที — ก่อนถูกส่งให้ host ที่ 500Hz การรอเฉลี่ยเพิ่มเป็นสองเท่าเป็นหนึ่งมิลลิวินาที

Input stack ของระบบปฏิบัติการ host รับ report ประมวลผลผ่าน USB driver, HID class driver และ input subsystem ตำแหน่งเคอร์เซอร์ถูกอัปเดตใน OS compositor และ raw input event ถูกส่งต่อให้เกม ขั้นตอนนี้ใช้หนึ่งถึงสามมิลลิวินาทีขึ้นกับ OS เวอร์ชันไดรเวอร์ และโหลดระบบ

การประมวลผลเอนจินเกม เกมรับ input event ใช้ logic การจัดการอินพุตของตัวเอง (ซึ่งอาจรวม sensitivity scaling, raw input vs buffered input และการสุ่มที่ขึ้นกับเฟรมเรต) และรวมการเคลื่อนไหวเข้าเฟรมที่เรนเดอร์ถัดไป ถ้าเกมรันที่ 60fps แต่ละเฟรมใช้ 16.7 มิลลิวินาที ซึ่งหมายความว่าการเคลื่อนไหวไม่สามารถปรากฏบนจอจนกว่าเฟรมถัดไปจะเรนเดอร์และนำเสนอให้จอ

การนำเสนอของจอ เฟรมที่เรนเดอร์เดินทางไปจอ ซึ่งนำเสนอที่ refresh interval ของตัวเอง ที่ 144Hz เฟรมปรากฏบนจอภายใน 6.9 มิลลิวินาทีของการมาถึง input buffer ของจอ

รวมขั้นตอนทั่วไป: เซนเซอร์ (0.25ms) + MCU (0.5ms) + USB ที่ 1000Hz (0.5ms) + OS (2ms) + เกมที่ 60fps (เฉลี่ย 8.3ms) + จอที่ 144Hz (3.5ms) = ประมาณ 15 มิลลิวินาที ขั้นตอน USB polling ก่อประมาณ 3% ของรวม เพิ่มเป็น 500Hz จะเพิ่ม 0.5 มิลลิวินาที เพิ่มรวมเป็น 15.5 มิลลิวินาที นี่คือเหตุผลที่ความแตกต่างที่วัดได้ระหว่าง 500Hz กับ 1000Hz ต่ำกว่าหนึ่งมิลลิวินาทีอย่างสม่ำเสมอ — อีก 96% ของไปป์ไลน์ไม่เปลี่ยน

นัยไม่ใช่ว่า polling rate ไม่เกี่ยวข้อง แต่มันเป็นชิ้นส่วนสุดท้ายที่ปรับให้เหมาะสม ถ้าเกมของคุณรันที่ 60fps การยกเฟรมเรตเป็น 144fps ตัด latency ไปป์ไลน์เฉลี่ย 4.9 มิลลิวินาที — ประมาณสิบเท่าของการประหยัดจากการเพิ่ม polling rate ถ้าจอของคุณรันที่ 60Hz การอัปเกรดเป็น 144Hz ตัดเฉลี่ย 4.9 มิลลิวินาที การเปลี่ยนทั้งสองยังก่อให้เกิดการปรับปรุงความคมชัดของภาพเคลื่อนไหวที่มองเห็นได้ที่การปรับ polling rate ไม่สามารถเทียบได้ ก็ต่อเมื่อเฟรมเรตและ refresh rate สูงอยู่แล้ว การก่อกำไรของ polling rate จึงกลายเป็นส่วนที่ใหญ่กว่าตามสัดส่วนของ latency ที่เหลือ และแม้แล้วก็ยังเป็นส่วนเล็กในเทอมสัมบูรณ์

ตัวเลขที่ควรจำ