نرخ نظرسنجی موش: ۱۰۰۰Hz یا ۵۰۰Hz؟
دوبرابرکردن نظرسنجی از ۵۰۰Hz به ۱۰۰۰Hz فاصلهٔ گزارش را از دو میلیثانیه به یک کاهش میدهد و میانگین انتظار زمانبندی را حدود نیم میلیثانیه. آن بهبود فقط بر یک مرحله از خطلولهٔ ورودی اثر میگذارد و بیشتر اهمیت دارد وقتی نوسازی نمایشگر، نرخ فریم و پردازش از قبل سریعاند. برای کار دفتری و بازی غیررقابتی، ۵۰۰Hz عموماً کافی است و ممکن است مصرف پردازنده یا باتری را کاهش دهد. یک تستر مرورگر میتواند الگوهای زمانبندی رویداد را آشکار کند، اما فقط یک ابزار نیتیو میتواند نرخ گزارش USB را تأیید کند.
بر حسب اعداد
| نرخ نظرسنجی | فاصلهٔ گزارش | میانگین انتظار زمانبندی |
|---|---|---|
| 125 Hz | 8.0 ms | 4.0 ms |
| 500 Hz | 2.0 ms | 1.0 ms |
| 1000 Hz | 1.0 ms | 0.5 ms |
| 2000 Hz | 0.5 ms | 0.25 ms |
| 4000 Hz | 0.25 ms | 0.125 ms |
| 8000 Hz | 0.125 ms | 0.06 ms |
جهش از ۱۲۵Hz به ۱۰۰۰Hz ۳.۵ms از میانگین انتظار زمانبندی حذف میکند. جهش از ۱۰۰۰Hz به ۸۰۰۰Hz حدود ۰.۴۴ms حذف میکند. اینها تفاوتهای مرحلهٔ نظرسنجی محاسبهشدهاند، نه اندازهگیریهای سرتاسری یک موش یا سیستم خاص.
سازندگان موش اکنون ۸۰۰۰Hz را بهعنوان یک مشخصهٔ تیتری تبلیغ میکنند، با جنباندزی روشن اینکه هرچیز پایینتر شما را عقب نگه میدارد. گام از ۵۰۰Hz به ۱۰۰۰Hz روی کاغذ واقعاً واقعی است، اما پیامد روی صفحه بهطور قابلتوجهی کمتر از آنچه عدد دوبرابرشده پیشنهاد میکند است و تعقیب نرخهای بالاتر هزینههایی دارد که مادیال بازاریابی حذف میکند. در اینجا حساب صادقانه است.
نرخ نظرسنجی واقعاً چه توصیف میکند
موش شما موقعیت خود را نمونهبرداری میکند و آن داده را بهفرکانس ثابتی به کامپیوتر انتقال میدهد. در ۵۰۰Hz هر دو میلیثانیه گزارش میدهد. در ۱۰۰۰Hz هر یک میلیثانیه. در ۸۰۰۰Hz هر ۰.۱۲۵ میلیثانیه. نرخ بالاتر یعنی بهروزرسانیهای موقعیت بیشتر، و بنابراین بالقوه تأخیر کمتر بین حرکت دست و پاسخ نشانگر. کلمهٔ عملی بالقوه است. نظرسنجی یک مرحله در یک خطلولهٔ تأخیر است و تقریباً هرگز طولانیترین نیست.
محاسبهای که همه نقل میکنند و زمینهای که حذف میکند
تفاوت بین ۱۰۰۰Hz و ۵۰۰Hz یک میلیثانیه در فاصلهٔ گزارش است. این کل مزیت قابلاندازهگیری در مرحلهٔ نظرسنجی است و چون حرکت در نقاط تصادفی درون فاصله رخ میدهد، صرفهجویی تحققیافتهٔ میانگین نزدیک به نیم میلیثانیه است. اکنون آن را در کنار سایر مراحل همان خطلوله بگذارید:
| مرحله | مدت زمانی نمونه |
|---|---|
| فاصلهٔ نظرسنجی در ۱۰۰۰Hz | 1ms |
| فاصلهٔ نظرسنجی در ۵۰۰Hz | 2ms |
| نوسازی نمایشگر در ۱۴۴Hz | 6.9ms |
| نوسازی نمایشگر در ۶۰Hz | 16.7ms |
| زمان فریم GPU در ۶۰fps | 16.7ms |
| واکنش بصری انسانی | ~۲۰۰ms (یک تأخیر خطلوله نیست — یک ردهٔ متفاوت کاملاً) |
| یک میلیثانیه کسبشده از دوبرابرکردن نرخ نظرسنجی یک خطای گردکردن در برابر نوسازی نمایشگر و رسم فریم است. توجه کنید که ~۲۰۰ms واکنش بصری انسانی فهرستشده در بالا یک ردهٔ متفاوت از اندازهگیری کاملاً است — زمان پردازش و پاسخ مغز به یک محرک بصری است، نه یک تأخیر در خطلولهٔ ورودی — پس تقسیم آن بر فاصلهٔ نظرسنجی یک مقایسهٔ معتبر نیست. این رابطهٔ نسبی کل دلیلی است که بسیاری از کاربران در استفادهٔ عادی نمیتوانند ۵۰۰Hz را از ۱۰۰۰Hz بهطور اتکاپذیر متمایز کنند، هرچند حساسیت به سختافزار، وظیفه و تفاوتهای فردی متغیر است. | |
 |
چهوقت ۱۰۰۰Hz و بالاتر واقعاً کمک میکند
نظرسنجی بالاتر عموماً وقتی مهم میشود که حلقههای دیگر زنجیر از قبل سریع باشند. مثلاً ممکن است شامل:
- یک نمایشگر نوسازی بالا، در محدودهٔ ۲۴۰Hz تا ۳۶۰Hz، تا صفحه بتواند بهروزرسانیها را در فواصل زیر چهارسانیمیلیثانیه واقعاً عرضه کند.
- نرخهای فریم پایدار بالا، بهطور قابلتوجهی بالاتر از نرخ نوسازی نمایشگر، تا فریمهای مصور وجود داشته باشند و آن فرصتهای نوسازی را پر کنند.
- تأخیر سیستم پایین سرتاسری، شامل اتصال مستقیم USB، پردازش پسزمینهٔ حداقلی و بدون overlays مسیر ورودی. درون آن پنجرهٔ رقابتی باریک و عمداً بهینهشده، برخی بازیکنان میتوانند ارزش واقعی از ۱۰۰۰Hz و گاهی از نرخهای بالاتر استخراج کنند. خارج از آن فایده سختتر قابلملاحظه است چون گلوگاه به جای دیگر میرود و گزارشهای اضافی ممکن است قبل از تأثیرگذاری چیزی مرئی درهمآمیخته یا نمونهگیری شوند.
هزینههای بالاتر بردن آن
نظرسنجی بالاتر رایگان نیست و بالای ۱۰۰۰Hz مصالحهها مادی میشوند:
بار پردازنده
هر گزارش از پشتهٔ ورودی سیستمعامل و غالباً موتور بازی عبور میکند. در چهار تا هشت هزار هرتز این زمان قابلملاحظهای از پردازنده مصرف میکند و روی سیستمهای ضعیفتر کاهش نرخ فریم حاصل میتواند تأخیر کل را بهجای کاهش افزایش دهد.
تخلیهٔ باتری
موشهای بیسیم عموماً در نرخهای بالا توان بیشتری مصرف میکنند و ۸۰۰۰Hz میتواند runtime بین شارژ را روی برخی مدلها بهطور قابلتأثیرتری کاهش دهد.
گزارشهایی که بهندرت به فایدهٔ مرئی ترجمه میشوند
یک موش ۸۰۰۰Hz هر ۰.۱۲۵ میلیثانیه گزارش میدهد در حالی که یک نمایشگر ۳۶۰Hz هر ۲.۸. بیش از بیست گزارش بین فریمهای متوالی میرسد؛ سیستمعامل و موتور بازی آنها را در کادنس خود درهممیآمیزند، batch میکنند یا نمونهمیگیرند، پس granularity اضافه بهطور اتکاپذیر به یک فریم مصور نمیرسد.
نرخ نظرسنجی نه کیفیت هدف است نه DPI
دو سردرگمی پایدار تصمیمات خرید را تحریف میکنند:
- DPI حساسیت سنسور است، که حرکت نشانگر بهازای هر اینچ حرکت فیزیکی را توصیف میکند. کاملاً مستقل از نظرسنجی است و برای راحتی کوک میشود نه تأخیر.
- کیفیت هدف از دقت سنسور، سطح، grip و تمرین مشتق میشود. یک موش ۱۰۰۰Hz با سنسوری که smoothing یا angle snapping دارد بدتر از یک موش ۵۰۰Hz با پیادهسازی سنسور تمیز هدف میگیرد. هیچکدام توسط مشخصهٔ نظرسنجی بهبود نمییابد و سازندگان از ابهام سود میبرند.
تأیید کنید واقعاً چه دریافت میکنید
نرخ پیکربندیشده و نرخ تأمینشده میتوانند واگرا شوند، اما یک مرورگر نمیتواند نرخ نظرسنجی سختافزار را مستقیم بخواند: رویداد موش در معرض درهمآمیزی مرورگر، زمانبندی main-thread و پردازش ورودی OS هستند، پس زمانبندی مبتنیبر وب نمیتواند فاصلهٔ گزارش USB واقعی را ثابت کند. برای اندازهگیری قابلاتکا از یک ابزار اختصاصی نیتیو که دادهٔ سطح USB را میخواند، یا نرمافزار سازندهٔ موش استفاده کنید. آنچه یک ابزار مرورگر مانند تستر موش ما میتواند مشارکت کند یک بررسی الگوی درشت است — فواصل بلند و سازگار غیرعادی بین بهروزرسانیهای ثبتشده میتواند اشاره به یک مسئلهٔ اتصال، درایور، گیرنده یا زمانبندی کند که ارزش تأیید با یک ابزار نیتیو دارد. مستقیماً به یک پورت مادربرد شناختهشدهخوب وصل کنید و دوباره تست کنید قبل از نتیجهگیری که موش مقصر است.
پیشفرضهای پیشنهادی
- موش گیمینگ باسیم: ۱۰۰۰Hz پیشفرض معقولی روی اکثر سیستمهای مدرن است؛ اگر مشکلات CPU یا frame-time مشاهده کردید پایین بیاورید.
- موش بیسیم: بسیاری از گیرندههای ۲.۴GHz مدرن ۱۰۰۰Hz را پشتیبانی میکنند، پس بر اساس اولویت انتخاب کنید: ۱۰۰۰Hz اگر کوتاهترین فاصلهٔ گزارش را میخواهید، یا ۵۰۰Hz اگر عمر باتری مهمتر است. تفاوت حسی برای بسیاری از کاربران سخت قابلتشخیص است، در حالی که صرفهجویی باتری در ۵۰۰Hz میتواند واقعی باشد.
- سیستم رقابتی با نمایشگر نوسازی بالا و نرخهای فریم بالا: ۱۰۰۰Hz تا ۲۰۰۰Hz را بیازمایید و صادقانه ارزیابی کنید آیا شما تفاوتی تشخیص میدهید. اگر نه، به پایین برگردید و فضای پردازنده را پس بگیرید.
- همهٔ دیگران، شامل اکثر استفادهٔ تولیدی: ۵۰۰Hz عموماً کافی است. تنظیم را فقط وقتی عیبیابی یک مسئلهٔ خاص است تأیید کنید.
USB چگونه گزارشهای موش را در سطح پروتکل مدیریت میکند
دستگاههای USB از طریق endpoint با میزبان ارتباط میکنند که هرکدام برای یک نوع انتقال خاص پیکربندی شده است. موشها از انتقالهای interrupt استفاده میکنند که فاصلهٔ نظرسنجی آن را کنترلر میزبان در بسامد پیکربندیشده زمانبندی میکند — میزبان آن time slotها را رزرو میکند، هرچند تحویل دنیای-واقعی همچنان میتواند تحت بار سیستم بلر بزند. دستگاه با هر دادهای که آماده دارد پاسخ میدهد. granularity زمانی به سرعت USB بستگی دارد: یک دستگاه Full-Speed (نوعی برای موشها) در فریمهای یکمیلیثانیهای زمانبندی میشود، در حالی که یک دستگاه High-Speed از microframeهای ۱۲۵-میکروثانیهای استفاده میکند. یک موش پیکربندیشده در ۱۰۰۰Hz بنابراین یک slot یکمیلیثانیهای روی یک اتصال Full-Speed میگیرد؛ معانی دقیقه endpoint-interval بین Full-Speed و High-Speed متفاوت است و کادنس گزارش واقعی همچنین به نحوهٔ declaration فاصله در descriptor دستگاه بستگی دارد. خود بستهٔ گزارش توسط descriptor HID دستگاه تعریف میشود که ساختار و اندازهٔ دادهای که موش میفرستد را اعلام میکند. یک گزارش استاندارد شامل یک بایت وضعیت دکمه، یک دلتای X، یک دلتای Y و اختیاراً چرخ و دادهٔ محور اضافی است. کل payload کوچک است — عموماً هشت تا شانزده بایت — که یعنی پهنای باند عموماً محدودیت اولیه نیست. محدودیت زمانبندی است: میزبان چندبار یک انتقال زمانبندی میکند، دستگاه چقدر سریع میتواند آن را پر کند و پشتهٔ ورودی سیستمعامل چقدر سریع میتواند آن را پرداز کند. در سطح سیستمعامل، هر گزارش دریافتشده یک interrupt را راهاندازی میکند که از پشتهٔ درایور USB، درایور کلاس HID و در نهایت زیرسیستم ورودی عبور میکند که موقعیت نشانگر را بهروزرسانی میکند یا رویداد را به برنامه پیشزمینه هدایت میکند. سیستمعامل هر گزارش را بهطور ساده به موتور بازی هدایت نمیکند؛ آنها را بر اساس طراحی پردازش ورودی خود batch میکند، درهممیآمیزد یا پردازش میکند، که یعنی لزوماً هر گزارش بر یک فریم مصور تأثیر نمیگذارد. این فهم سطح پروتکل چند نکته را روشن میکند. اول، نرخ نظرسنجی یک ویژگی از پیکربندی endpoint USB است نه از سنسور موش — سنسور میتواند به بسامد خود مستقل نمونهبرداری کند. دوم، یک میزبان و دستگاه سازگار میتوانند گزارشها را در فاصلهٔ پیکربندیشده زمانبندی کنند، اما کادنس واقعی همچنان به descriptor، فیرمور، اتصال و زمانبندی سیستمعامل بستگی دارد. سوم، هزینهٔ پردازش در نرخهای حدی تجمع مییابد و میتواند کارایی بازی را روی برخی سیستمها کاهش دهد. مشخصه یک کادنس زمانبندی را توصیف میکند نه ضمانت بهبود ادراکی، و لایههای بین سیم و صفحه هرکدام تأخیری وارد میکنند که نرخ نظرسنجی نمیتواند پوشش دهد. نکتهٔ ظریفتر این است که زمانبندی کنترلر USB کاملاً قطعی نیست. کنترلر میزبان چندین دستگاه اشتراکی روی همان bus را مدیریت میکند و ترافیک دیگر میتواند تغییرات زمانی کوچکی وارد کند. اندازهٔ آن تغییر به کنترلر، درایورها، دستگاههای متصل و سیستمعامل بستگی دارد، پس باید اندازهگیری شود نه فرض شود. یک پورت مستقیم مادربرد یک مقایسهٔ تشخیصی معقول است، اما USB 3.x برای یک موش ذاتاً الزامی نیست.
یک میلیثانیه حداکثر تفاوت فاصله بین ۵۰۰Hz و ۱۰۰۰Hz در مرحلهٔ نظرسنجی است. واقعی و قابلاندازهگیری است، اما برای بسیاری از کاربران سخت قابلملاحظه است. سایر مراحل خطلوله — زمان فریم GPU، پردازش OS و نوسازی نمایشگر — میتوانند بسیار بیشتر مشارکت کنند و هیچ تنظیم موشی نمیتواند آنها را کوتاه کند. اگر یک موش گیمینگ و یک مانیتور نوسازی-بالا دارید، ۱۰۰۰Hz نقطهٔ آغاز معقولی است، اما بار CPU، frame time، مصرف باتری و تجربهٔ خودتان را ارزیابی کنید نه اینکه آن را بهعنوان یک الزام جهانی تلقی کنید.
برای فهمیدن اینکه نرخ نظرسنجی کجای زنجیر تأخیر کلی نشست، کمک میکند یک حرکت منفرد موش را از سطح فیزیکی تا تغییر مرئی نشانگر در هر مرحله ردیابی کنیم. هر مرحله زمانی مشارکت میکند و نظرسنجی فقط یکی از آنهاست. نمونهبرداری سنسور. سنسور نوری در موش شما تصاویر سطح را با یک نرخ داخلی بالا میگیرد — عموماً ۱۲۰۰۰ تا ۱۶۰۰۰ فریم در ثانیه — و فریمهای متوالی را برای محاسبهٔ حرکت مقایسه میکند. این فرآیند کاملاً داخلی به سنسور است و در بسامد خود مستقل از نرخ نظرسنجی USB کار میکند. سنسور یک دلتای موقعیت تولید و آن را به میکروکنترلر موش میسپارد. پردازش میکروکنترلر. MCU دلتای سنسور را دریافت میکند، هر پردازش پیکربندیشده مانند angle snapping، smoothing یا شتاب را اعمال میکند و آن را در یک بستهٔ گزارش USB جمع میکند. این مرحله یک تأخیر کوچک اما ناصفر اضافه میکند — مدلهای نمونهای زیر یک میلیثانیه روی فیرمور خوبمهندسیشده پیشنهاد میکنند، اما مقادیر واقعی به دستگاه متغیر است و روی دستگاههای با پردازش DSP سنگین طولانیتر میشود. انتقال USB. این مرحلهای است که نرخ نظرسنجی کنترل میکند. در ۱۰۰۰Hz، گزارش جمعشده برای انتقال interrupt بعدی برنامهریزیشده منتظر میماند که هر یک میلیثانیه رخ میدهد. بهمیانگین، گزارش نصف آن فاصله — ۰.۵ میلیثانیه — را قبل از انتقال به میزبان انتظار میکند. در ۵۰۰Hz، انتظار میانگین به یک میلیثانیه دوبرابر میشود. پشتهٔ ورودی سیستمعامل. میزبان گزارش را دریافت میکند، آن را از طریق درایور USB، درایور کلاس HID و زیرسیستم ورودی پردازش میکند. موقعیت نشانگر در compositor OS بهروزرسانی میشود و رویداد input خام به بازی هدایت میشود. این مرحله عموماً در یک تا سه میلیثانیه مدلسازی میشود بسته به OS، نسخهٔ درایور و بار سیستم — بهعنوان بازهٔ نمونهای تلقی کنید، نه اندازهگیری هر سیستم خاص. پردازش موتور بازی. بازی رویداد ورودی را دریافت میکند، منطق پردازش ورودی خود را اعمال میکند (که ممکن است شامل مقیاسبندی حساسیت، ورودی خام در برابر ورودی بافرشده و نمونهبرداری وابستهبه-نرخ-فریم باشد) و حرکت را در فریم مصور بعدی ترکیب میکند. اگر بازی در ۶۰fps اجرا میشود، هر فریم ۱۶.۷ میلیثانیه طول میکشد، که یعنی حرکت نمیتواند روی صفحه ظاهر شود تا فریم بعدی مصور و به نمایشگر عرضه شود. عرضهٔ نمایشگر. فریم مصور به مانیتور سفر میکند، که آن را در فاصلهٔ نوسازی خود عرضه میکند. در ۱۴۴Hz، فریم ظرف ۶.۹ میلیثانیه از رسیدن به input buffer نمایشگر روی صفحه ظاهر میشود. جمعبندی مراحل نمونهای با انتظارهای میانگین با یک مدل نمونهای (نه اندازهگیری هر موش یا بازی خاص): سنسور (~۰.۲۵ms) + MCU (~۰.۵ms) + USB در ۱۰۰۰Hz (~۰.۵ms انتظار میانگین) + OS (~۲ms) + بازی در ۶۰fps (~۸.۳ms انتظار میانگین فریم) + نمایشگر در ۱۴۴Hz (~۳.۵ms انتظار میانگین نوسازی) ≈ تقریباً ۱۵ میلیثانیه کل. در این مدل، مرحلهٔ نظرسنجی USB تقریباً ۳٪ کل را مشارکت میکند. دوبرابرکردن فاصله به ۵۰۰Hz ~۰.۵ میلیثانیه بهمیانگین اضافه میکند و کل را به ~۱۵.۵ میلیثانیه افزایش میدهد. به همین دلیل تفاوت اندازهگیریشده بین ۵۰۰Hz و ۱۰۰۰Hz همواره زیر یک میلیثانیه است — بقیهٔ خطلوله تغییر نمیکند. این ارقام یک مدل نمونهای است، نه اندازهگیری هر موش، OS یا بازی خاص؛ مقادیر واقعی کاملاً به سختافزار، درایور و نرمافزار خاص شما بستگی دارد. پیام این نیست که نرخ نظرسنجی بیاهمیت است، بلکه آخرین مؤلفهای است که باید بهینهسازی شود. با همان مدل انتظار-میانگین، اگر بازی شما در ۶۰fps اجرا میشود، بالا بردن نرخ فریم به ۱۴۴fps حدود ۴.۹ میلیثانیه از انتظار میانگین فریم حذف میکند (۱۶.۷ms/۲ منهای ۶.۹ms/۲) — تقریباً ده برابر صرفهجویی از دوبرابرکردن نرخ نظرسنجی. اگر نمایشگر شما در ۶۰Hz اجرا میشود، ارتقا به ۱۴۴Hz حدود ۴.۹ میلیثانیه بهمیانگین حذف میکند (۱۶.۷ms/۲ منهای ۶.۹ms/۲). اعداد دقیق به اینکه انتظار میانگین، زمان فریم کامل یا تأخیر سرتاسری را اندازه میگیرید بستگی دارد، پس آنها را نمونهای تلقی کنید نه جهانی. هر دوی آن تغییرات همچنین بهبودهای مرئی در وضوح حرکت تولید میکنند که تنظیمات نرخ نظرسنجی نمیتوانند برابری کنند. فقط وقتی نرخ فریم و نرخ نوسازی از قبل بالا هستند سهم نرخ نظرسنجی بهنسبت یک برش بزرگتر از تأخیر باقیمانده میشود و حتی آنگاه در اصطلاحات مطلق کوچک میماند.
یک عدد برای یادآوری
۱۰۰۰Hz میتواند فاصلهٔ مرحلهٔ نظرسنجی را تا یک میلیثانیه نسبت به ۵۰۰Hz کاهش دهد، که واقعی است اما اغلب سخت قابلملاحظه. بهطور مستقیم بهسوی نرخ نوسازی نمایشگر و نرخ فریم پایدار بهینهسازی کنید، چون آن مراحل میتوانند تأخیرهای بسیار بزرگتری مشارکت کنند، و سپس ارزیابی کنید آیا تغییرات نرخ نظرسنجی چیزی که میتوانید ادراک کنید را تغییر میدهد. ۸۰۰۰Hz را بهعنوان یک گزینهٔ گزارشدهی با-بسامد-بالا تلقی کنید نه یک ارتقای حسی تضمینی تا وقتی بقیهٔ خطلوله بتواند از آن استفاده کند.