鼠标回报率测试
回报率(轮询率)是鼠标每秒向电脑报告位置的次数,单位 Hz。1000Hz 意味着约 1ms 报告一次,数值越高光标越跟手。点下面的按钮开始,然后在这个页面的任意位置按住并快速画圈——画得越快,读数越接近真实值。
实时回报率
每根柱子是一个 200ms 窗口的实测值,横轴是时间。稳定的鼠标应该是一排差不多高的柱子;橙色柱子表示这个窗口明显低于标称档位——多半是那一瞬间画慢了,而不是鼠标出了问题。
参考值
下面是常见档位。间隔就是 1000 ÷ Hz——鼠标每多少毫秒报告一次位置。
| 回报率 | 间隔 | 常见定位 | 说明 |
|---|---|---|---|
| 125 Hz | 8 ms | 办公 / 基础鼠标 | 光标移动能看出台阶感 |
| 250 Hz | 4 ms | 入门游戏 | 比 125Hz 明显跟手 |
| 500 Hz | 2 ms | 游戏 | 大多数玩家的性价比档位 |
| 1000 Hz | 1 ms | 专业电竞 | 目前最主流的高端档位 |
| 2000 Hz | 0.5 ms | 高端电竞 | 需要 144Hz 以上屏幕才看得出差别 |
| 4000 Hz | 0.25 ms | 顶级电竞 | CPU 占用开始变得可观 |
| 8000 Hz | 0.125 ms | 旗舰 | 刷新率会先成为瓶颈 |
怎么看结果
- 当前回报率用的是计数法:在最长的一段连续运动里,拿样本数除以时长。浏览器会拖延事件的派发,但不会丢报文,所以事件总数和总时长都是准的,相除正好把派发的抖动平均掉。这是浏览器里唯一无偏的算法。
- 判定档位是把实测值归到最近的标称档位,容差 ±8%。超出容差就显示“未识别”,不硬凑——880Hz 不会替你说成 1000Hz。
- 峰值是把这段运动切成 200ms 的窗口,取其中最高的一个,反映这只鼠标最多能跑到多少。它天生会比真实值略高——一组带噪声的数里取最大值,拿到的总是“真值 + 正向噪声”。好在每个窗口的噪声很小,3 秒数据上通常只高出 1% 左右,当作上界看就好。
- 窗口波动是各窗口速率的离散程度,反映读数稳不稳。它和峰值一样建立在计数上,不碰间隔,所以在浏览器里是可信的。通常 5% 以内属于稳定。
- 移动速度——这是读数偏低时最该先看的数字。鼠标只在产生了新位移时才发报文,所以每秒报文数 ≈ 每秒移动的像素数。这不是 bug,但移动太慢时测出的数值没有意义。
中途松开鼠标不影响结果
你松手、换方向的瞬间不会产生任何指针事件,缓冲区里会留下一个几百毫秒的空档。本页的做法是在空档处把序列整段切开,只在最长的连续段上做统计。这也是“每次测都不一样”的根源:如果直接把空档算进去,一个 500ms 的停顿混进2000 个 1ms 的间隔里,平均值会从 1ms 变成 1.25ms,读数从 1000Hz 掉到 800Hz——而它跌多少,完全取决于你什么时候松手。
本页不提供“抖动”“掉包率”
这是刻意的,而且是被实测逼出来的。这类指标都要靠相邻事件的间隔算,而间隔恰恰是浏览器里最不可信的东西:时间戳是浏览器处理到这条消息的时刻,不是硬件上报的时刻,实测有 0.3–0.6ms 的批处理延迟(原生驱动接口只有 ±2µs)。1000Hz 的周期是 1ms,这点延迟足以让一个完全正常的间隔越过任何“偏长”的门槛,于是好鼠标也会稳定报出百分之几的掉包率。把门槛往上调只是把这个假象藏起来,治不了根,所以本页不给这类数字。页面上保留的每一个指标——回报率、峰值、窗口波动——都只建立在计数上。
读数会偏的几种情况
- 移动太慢。每秒报文数 ≈ 每秒移动的像素数。要打满 1000Hz,你需要在屏幕上每秒移动约 1000 像素;要打满 8000Hz 就是每秒 8000 像素。页面上的“移动速度”会实时告诉你够不够。画圈要甩开膀子画——整个页面都是测试面,不必拘束在某一块区域里,幅度越小速度越上不去,读数就越低。
换个写法:每秒报文数 = DPI × 每秒移动的英寸数。800 DPI 要每秒推 1.25 英寸(约 3 厘米)才够 1000Hz,1600 DPI 只要一半。所以读数偏低时,先把 DPI 调高通常比甩得更快省力得多。 - 时间戳被钳在 100µs,逐条间隔没有意义。浏览器只在页面处于跨域隔离时才给出 5µs 精度的时间戳,否则钳在100µs。8000Hz 鼠标的报文周期是 125µs,和量化台阶是同一个数量级,落进同一格的报文会被丢在一起——本页会实时统计这个比例,一旦偏高就把数据质量判为“不可信”。但主读数不受这一条限制:它用的是「报文数 ÷ 时长」,量化只作用在首尾两个时间戳上,几秒的运动里那是万分之一级的误差。真正会让它偏低的是被丢掉的报文和浏览器自身的批处理,所以 4000Hz 以上把这个数当下限看。页面顶部会标明当前精度(本站用 service worker 在 GitHub Pages 上补出了隔离,浏览器支持的话那里显示的就是 5µs)。
- 不是 HTTPS——Chrome 142 起,合并事件只在安全上下文中可用。用 http 访问时本页会直接失效,顶部会有提示。
- Firefox——部分版本把合并事件的时间戳设为 0,此时只能给出平均回报率,无法给出峰值和窗口波动。这是浏览器实现差异,不是你的鼠标问题。
- 无线鼠标——接收器插在 USB 3.0 口旁边可能受干扰,读数会不稳。可以换个口再测。
常见问题
最常见的原因是移动速度不够,而不是鼠标有问题。鼠标只在产生了新位移时才发报文,所以每秒报文数 ≈ 每秒移动的像素数。要打满 1000Hz,你需要每秒在屏幕上移动约 1000 像素;要打满 8000Hz 就是每秒 8000 像素,那已经相当快了。本页会实时显示你的移动速度,读数偏低时先看它。其次要确认驱动里确实开了高回报率模式——有些鼠标出厂默认是 125Hz,不装驱动改不了。无线鼠标的接收器插在 USB 3.0 口旁边也可能受干扰。
按可能性从高到低排:第一是移动速度,也就是上一问那条——鼠标只在产生新位移时才发报文,推得慢自然读不满,先看页面上的“移动速度”够不够。第二是系统与驱动:Windows 会限制非前台窗口接收原始输入(测的时候让本页保持聚焦),有些无线鼠标会为省电动态调整回报率,接收器挨着 USB 3.0 口也可能受干扰。第三才是浏览器:它派发指针事件本身有开销,回报率越高打折越多,有浏览器工具作者实测 4000Hz 以上比硬件级工具低一两成;要拿硬件级的数字得用操作系统底层的接口(如 Windows Raw Input),那不是网页能做的。所以本页在 4000Hz 以上给出的数请当作下限看。
当前回报率是在最长的一段连续运动上,用样本总数除以总时长算出来的,最稳,适合判断鼠标实际工作在哪个档位。峰值是把这段运动切成 200ms 的小窗口,取其中最高的那个,反映“这只鼠标最多能跑到多少”。峰值天生会比真实值略高一点,因为它是许多个带噪声的窗口里取最大值;当作上界看,不要当作典型值。
收益是递减的。125Hz 到 500Hz 是质的差别,500Hz 到 1000Hz 明显,1000Hz 往上对绝大多数人已经难以分辨——屏幕刷新率通常先成为瓶颈。更高的回报率还会增加 CPU 占用,8000Hz 鼠标通常占 1–2%。
不会。松手和换方向的瞬间不产生任何指针事件,程序会在这些空档处把数据整段切开,只在最长的一段连续运动上做统计。这正是本页读数比同类工具稳定的原因——把空档算进去的算法,结果会取决于你什么时候松手,每次测出来都不一样。
因为它们在浏览器里误差太大,给出来只会误导人。这类指标都要靠相邻事件的间隔计算,而浏览器给事件打的时间戳是它自己处理到这条消息的时刻,实测有 0.3–0.6ms 的批处理延迟,而 1000Hz 的周期只有 1ms。一个完全正常的间隔光靠浏览器自身的延迟就能变成 1.6ms,于是任何“明显偏长就算掉包”的判据都会让一只好鼠标报出百分之几的掉包率。本页只给计数类的结论。
