我们如何研究 Windows
本页内容
在「Windows 研究」板块中，我们验证具体的技术论断。每篇文章都会说明我们验证了什么、在什么条件下验证，以及结果适用于哪些系统。
参数的存在、它对系统运行的影响以及性能提升，都需要单独的证明。
什么算作证据
Section titled “ 什么算作证据”我们使用几种相互独立的证据类型：
- 一手文档。 Microsoft 官方文档、规范以及硬件或应用厂商的文档。
- 静态观察。 特定组件版本中实现方式的迹象。此类观察仅限于所研究的构建版本，其本身并不能证明该路径在运行期间会被执行。
- 动态观察。 在所述场景中获取的系统事件、组件状态和跟踪记录。
- 受控测量。 在已知变更并已验证状态回退的情况下，对预先选定的指标进行比较。
- 复现。 在独立运行、另一系统或构建版本上重复得到结果。
采集与处理的内部自动化方式不予公开。这不改变披露以下内容的要求：所验证的问题、配置、指标、运行次数和限制条件。
| 状态 | 含义 |
|---|---|
| 已记录 | 行为在一手公开来源中已有描述。 |
| 已观察 | 事件或状态在指定环境中被发现。 |
| 已测量 | 按所述方法获得了数值差异。 |
| 已复现 | 结果被独立重复。 |
| 未复现 | 所声称的效果在指定条件下未被发现。 |
| 数据不足 | 方法或样本不足以得出结论。 |
状态针对的是单个论断，而不是自动针对整篇文章。我们不使用任意的置信百分比，也不会在没有其他系统上验证的情况下称结果已被普遍证明。
实验如何构建
Section titled “ 实验如何构建”在测量之前固定以下内容：
- 一个待验证的问题；
- 自变量；
- 主要指标及其单位；
- Windows build、关键硬件、驱动程序和应用程序版本；
- 具有实际意义的阈值；
- 恢复初始状态的方式。
我们比较初始状态与变更后的状态，然后验证是否回退。在可能的情况下，交替进行成对运行的顺序。我们控制预热、供电、温度和后台负载；如果无法做到，则说明该限制。
同一条跟踪记录中的各个区间可以显示随时间发生的变化，但不被视为独立的重复。虚拟机的测量结果不能自动套用到物理计算机上。要得出关于某一类所有设备的结论，仅测试一台设备是不够的。
物理 click-to-photon 测试台
Section titled “ 物理 click-to-photon 测试台”对于游戏研究，我们使用自有的硬件测试台。它物理测量从鼠标按键的电信号到屏幕上像素亮度变化之间的完整延迟，而不通过软件估算这一区间。
主要链路的结构如下：
- 导线焊接在第一代 Logitech G PRO X SUPERLIGHT 左键线路上。电信号前沿启动 Arduino Uno 计时器。
- 同一次点击经过鼠标控制器、USB、Windows、游戏、渲染队列、GPU 和显示器。
- 固定在屏幕上的光传感器在测试区域亮度越过预先选定的阈值时停止计时器。
- 一个结果包含以毫秒为单位的完整 click-to-photon 区间。
这样的起点有意包含了鼠标控制器的处理及其 click debounce，但不包含按键在触点闭合前的机械行程。我们不会从最终数值中减去鼠标延迟。在 RTINGS 的当前独立测量方法中，G PRO X SUPERLIGHT 通过线缆为 2.5 ms，通过 receiver 为 3.1 ms。较低的实测 click latency 使这款鼠标适合作为测试台的稳定组成部分，但不会使结果变成纯粹的 Windows 或游戏延迟。
另一种 Arduino Nano 规格的独立 HID 微控制器可以自动向 Windows 发送点击。当需要消除手动按压的差异并以受控节奏重复输入信号时，会使用这条路径。它回答的是另一个问题，不会与从鼠标按键物理线路开始的系列混在一起。
在 CS2 中使用 workshop 地图 BXLAT，其中点击会引发测试区域可预测的变化。Valorant 中也采用类似的视觉场景。光传感器的位置、分辨率、显示器刷新率、FPS 上限、display scaling 模式、presentation mode 和光阈值在整个被比较的系列中保持固定。
当前标准要求每个状态至少 300 次有效点击。在新的系列中，我们保存平均值、标准差、最小值、最大值、百分位数（包括 P90）以及用于绘制图表的分布。错误触发、超时以及超出预先设定范围的值会被标记，并在检查系列适用性时予以考虑。
在该测试台上进行的研究已持续数年，期间存储格式发生过变化。在历史测量公开表格中，既有每次 300 次点击的系列，也有更早的每次 100 次的系列。对于部分旧测试，仅保存了 AVG、STDDEV、MIN 和 MAX；缺失的 P90 或图表无法从聚合数据中恢复，并会被明确标记为不可用。新的系列将随扩展统计信息一起发布。
结果中会发布什么
Section titled “ 结果中会发布什么”文章包含：
- 简短回答；
- 待验证的论断；
- 研究范围；
- 方法及独立跟踪记录的数量；
- 指标数值及离散程度；
- 已证实和未证实的结论；
- 被排除或受污染的指标；
- 限制条件；
- 不保证结果相同的实用建议；
- 状态回退的确认；
- 一手公开来源及验证日期。
如果结果未能证实某个流行建议或 BoosterX 功能，它仍然可以被发布。产品中存在某项设置并不构成其有效性的证明。
如何自行验证
Section titled “如何自行验证”我们研究中相当一部分动态观察可以用公开工具重复：Sysinternals ProcMon 用于系统跟踪，WinDbg 配合Microsoft 公开符号。基本的验证路径如下。
- 读取参数 — ProcMon。 打开 Options → Configure Symbols，并指定 Microsoft 公开符号服务器，以便堆栈显示模块和函数名称。然后添加 Path contains 过滤器——例如来自
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile的SystemResponsiveness。通过读取事件可以看到该值是否被读取、何时被读取以及由哪个进程读取。 - 谁在读取 — 调用堆栈。 双击事件可打开其属性；Stack 选项卡显示模块链——这就是参数的「读取者」。例如，从
user32.dll到win32kfull.sys的链意味着该值由 Win32k 子系统负责。 - 运行时行为 — WinDbg。 使用 Microsoft 公开符号，可以在堆栈中的函数上设置断点，并查看读取到的值是如何被应用的。
- 合成测试。 更改该值并测量可观察到的行为。例如，鼠标输入间隔可通过公开的轮询率测试工具测量。
诚实的边界。 文章中不会发布二进制文件的静态分析和完整跟踪记录。上述路径重复了我们观察中的动态部分，但不能替代静态分析——其结论仅适用于所研究的构建版本。
延迟测量的边界
Section titled “ 延迟测量的边界”软件延迟、队列深度、音频引擎周期、线程调度时间和完整物理延迟描述的是不同的量。例如，XAudio2 队列并不能决定从用户操作到扬声器发声的整个区间。要测量它需要外部设备。
同样，单个进程的 CPU 时间并不等于对 FPS、frametime、能耗或系统响应性的总体影响。此类结论需要通过单独的指标来验证。
原始 ETL、PML、事件日志、内存转储和注册表导出默认不予公开。系统跟踪可能包含用户名、路径、命令行、网络地址和其他敏感数据。Microsoft 在 Sysinternals 条款中对此有专门警告。
网站上只发布经人工筛选和匿名化处理的表格。我们会删除设备与安装的唯一标识符、用户路径、账户数据、网络标识符、登录凭据以及与本研究无关的进程信息。
Windows、驱动程序和应用程序都在变化。每篇文章都会标注最后验证日期和适用范围。如果新的测量结果与旧结论相矛盾，文章会更新并说明原因。旧结果不会自动套用到新的构建版本上。
独立性与商标
Section titled “ 独立性与商标”研究由 BoosterX 团队发布，可能涉及产品功能。这一潜在利益冲突通过将方法、测量数值、限制条件和负面结果与产品建议分开来加以处理。
BoosterX Wiki 是独立出版物，与 Microsoft Corporation 无关联、未获其授权、未受其赞助，也未获其认可。Microsoft 和 Windows 名称仅用于准确描述研究对象。详情：Microsoft Trademark and Brand Guidelines。
- 2026-08-24： 方法发布。
- 2026-09-20： 新增「如何自行验证」章节；修正了鼠标数据来源链接。
方法最后验证日期：2026-09-20。