最近接了个国产鼠标的推广，测轮询率的时候越测越感觉不对劲，越测越奇怪，包括之前测G502X的轮询率也是，轮询率的最终测试数据，总是破不了1000Hz……
G502X那个还好，毕竟上限就是1000Hz，达不到1000Hz倒也说得通，但手头这个测起来是真不对劲，因为厂家宣称8000Hz的回报率，实际测出来只有185Hz……
异常的测试数据
呃，所以是厂家虚标、搞虚假宣传？md，这能忍？起诉！必须起诉，告它丫的……
还真不是……因为测试的时候明显感觉到异常了！
最直观的表现就是，当我开启8000Hz回报率的时候，我的CPU风扇转速会直接上升一个台阶！相比1000Hz时接近10%的CPU占用率，开启8KHz回报率之后，我的CPU占用率来到了20%。高轮询率设备对CPU的负担是比较大的，所以这款鼠标，厂家并没有虚假宣传！
问题只能是出在软件上了，也必然是出在软件上！
我常用来测试鼠标轮询率的软件——《Mouse Rate Checker》，是一款自1999年之后就停止更新的软件，截止到2024年，25年的时间里，没有任何人进行过维护工作，所以……就算出现什么问题，也很正常，对吧？
而且作者在描述文件里，也留下来一段值得思考（耐人寻味）的话用来甩锅：
“It's possible that the rate is a bit inaccurate, especially at
high rates (>=100Hz). Try to uncheck the "show current rate" checkbox,
which should lower CPU usage and close all other applications.
If it's still inaccurate, blame Windows, not my program. ;-)”
大致意思是：
“轮询率的数据可能会有一点儿不准确，尤其是在高轮询率（≥100Hz）的时候。尝试取消勾选‘show current rate（实时轮询率显示）’复选框，这将减少CPU占用率并关闭其他程序。如果它仍不准确，那就是Windows的锅，不是我的。”
实际上用下来，我怀疑作者当初手抖，少给100Hz打个零！这个软件对1000Hz以内轮询率的设备，都挺友好的，测试数据都很正常，只有超过1000Hz时，才会不对劲！
具体表现为，超过1000Hz过多的部分，有概率会变成三位数……比如我开启了8000Hz的回报率，这个软件会把实时回报率显示成三位数，然后平均回报率也会出错hhhhh
异常的数据
至于解决办法，就是像原作者说的那样，把“show current rate”复选框的“√”去掉！这样虽然不能显示实时轮询率了，但至少Average（平均轮询率）的数据会恢复正常。
Average（平均轮询率）的数据恢复正常
实测取消勾选之后，最大能测4000Hz的轮询率，再高就上不去了，而且即便是4000Hz，这软件也不是很好使……取消勾选之后，勉强算是支持到2000Hz吧……换言之，这个软件，就当它是1000Hz的上限，再高的轮询率，就得考虑用别的软件测了，或者自己写一个……
其实像这种情况，还蛮多的！仅仅是我在测试的时候，就遇到好几个！我找了好几个在线检查鼠标回报率的网页，想排查下问题，结果大家都不约而同的翻车，出现了问题！稍微好点儿能测到2000Hz的轮询率，稍微差点的就只能支持到1000Hz，而且实时反馈的延迟还比较高……
这本质上就和测速软件差不多，扯了条1000M的宽带，结果测速软件的服务器只有500M，所以无论你怎么测，你的千兆宽带只能测出来500兆的速度，不是你宽带有问题，而是协助你测试的服务器本身存在问题。
所以如果把这类情况拓展延伸一下，说白的直白些，就是有些软件可能压根不支持高轮询率设备，对高轮询鼠标没有优化，甚至是负反馈！
更具体点，举个十分抽象且逆天的例子，假设我开发了一款FPS游戏，鼠标轮询率接入就故意锁到125Hz，更高的轮询率无法支持，这时候，就算换个8KHz轮询率的鼠标，照样和125Hz回报率的鼠标是一个水平……
啊，所以说，就现在的情况而言，自己写个轮询率测试程序，还是很有必要的！至于说怎么写，我还真不会，我已经好久没敲代码了hhhhh……（你现在让我去写C，我还真不一定写得出来，最起码是要先看看语法的……）
还是聊聊设计思路吧，到底怎么实现测试鼠标轮询率的逻辑！
不瞒你说，我最初的想法其实蛮天真的……
我觉得无论是手柄还是鼠标，操作系统内都应该会有个API（Application Program Interface应用程序接口），这个API牛逼到不用我自己写算法，可以直接向我实时反馈鼠标或者手柄摇杆轮询率信息，而我只需要把这个数据用printf展示出来就行……
这个想法看上去很美好，但实际上无从下手，我找不到这么牛逼屌到爆的API……
所以大部分开发者在应对这个问题时，都是另辟蹊径，选择了另一种巧夺天工的思路——那就是“算法”！
既然从系统内无法直接拉到这个参数，那我就把轮询率，算出来！
大致思路是这样：记下鼠标或者摇杆位置信息，时间记为t1；每当X轴、Y轴有一个发生变动或者同时发生变动时，记下时间t2，t2-t1就是这两次传回信息所需要的时间间隔，也就是轮询率的周期，这样就把轮询率算出来（具体实现起来要把算法循环，还要考虑t1和t2的刷新问题）。就比如当前鼠标每隔8ms传回了一次位置数据，它的轮询率就是8ms为周期，那它的回报率就是1000ms÷8ms，即125Hz。
理论上写个这样的测试软件，直接用C语言写个控制台程序是最简单解决方案，也不用考虑UI适配问题，唯独就是我，真的好几年没碰Dev C++了……
好了，这期闲聊就这样，爷要睡觉了！
下面是一段追加内容，因为写完专栏之后还是感觉不对劲：
既然测试鼠标轮询率，是通过算法实现的，那必然存在误差，遇上轮询率较为稳定的设备一般不会出问题，可一旦遇上不稳定的设备，那就看算法作者自身的水平了！
假设我有一台设备，它与PC沟通的方式是上一次1ms（1000Hz），下一次20ms（50Hz），那它的平均轮询率到底该怎么算？
是按照1000ms÷（20ms+1ms）×2=96Hz来算？
还是取足够多的样本，比如（1000Hz+50Hz）÷2=525Hz来算呢？
这或许就是诸多轮询率测试软件出错的原因……
如果参考PC平台显卡测试游戏帧率表现的评价，平均帧并没有太大的参考价值……最低帧反而是用户应该关心的，所以针对于鼠标轮询率的测试，在个别设备轮询率不稳定的状态下，最低轮询率，才是最具有参考价值的参数！
因为设备从1000Hz突然跳到50Hz，它是真的卡，可以感知的卡……
像这种奇葩情况，某国际大牌数位板可谓是惯犯了……
测轮询率，应该看实时轮询率反馈，看最低值，而不是看平均值！
