Win32PrioritySeparation：CPU 满载时的延迟与 FPS

本页内容

简短回答： Win32PrioritySeparation 确实控制 foreground boost 以及部分 CPU 时间片策略。我们的历史测试并未发现普遍最优的值。Windows default 显示出略低的平均 click-to-photon 延迟，而 0x1A 在一次 100% CPU 负载的测试中与最佳 FPS 和 P1 相符。由于缺少独立的 FPS 重复测试和原始 click samples，我们推荐 default，并将 0x1A 仅视为针对 CPU 场景的可验证假设。

状态： 该参数与 foreground boost 的关联已由 Microsoft 记录。在先前采集的 Windows 11 24H2 和 25H2 系统跟踪中观察到了对该参数的读取。用户效果是在历史性的 Windows 10 22H2 系列中测量的，但未在其他系统或独立运行中复现。

可验证的论断

我们验证了三个不能合并的论断：

该参数存在，并与 Windows 调度器策略相关。
值 0x02 和 0x1A 在相同的最大 foreground boost 下代表不同的时间片策略。
0x1A 在 CPU 满载时改善 FPS 或游戏延迟。

前两个论断由公开文档和对所研究版本的观察得到证实。第三个需要测量，不会仅因参数的构造而成立。

研究范围

层面	环境	结果
公开文档	Microsoft WMI、CPU Analysis 和 Windows Internals	描述了 foreground boost、quantum 和历史位结构
系统观察	Windows 11 24H2 和 25H2	在先前采集的跟踪中观察到了对该参数的读取
Click-to-photon	Windows 10 22H2、Valorant、CPU 100%	每个值 300 次测量，保存了聚合数据
FPS	同一历史系列	每个配置一次 CapFrameX capture；部分行因 capture 挂起而不适用

本出版物没有 Windows 10 22H2 的动态跟踪。Windows 11 26H1 也没有可用的跟踪。Windows 10 的测量结果不能在不重复的情况下套用到 Windows 11。

参数所在位置

字段	值
Hive 和路径	`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl`
值名称	`Win32PrioritySeparation`
类型	`REG_DWORD`
记录的 client Windows 初始值	`0x02` (`2`)

Windows Internals 将 2 称为客户端 Windows 以及未配置为 application server 的服务器的初始值。在我们的 Windows 11 25H2 跟踪中，DWORD 也明确存在，值为 2。

因此我们不认为值缺失是普遍的 Windows default。它可能出现在镜像修改、手动删除或第三方工具操作之后，但在当前研究中，DWORD 缺失的 clean-install 场景并未动态复现。不能自动将缺少该行解释为 0。

参数的构造

Microsoft 将属性 Win32_OperatingSystem.ForegroundApplicationBoost 与 Win32PrioritySeparation 对应，并记录了值 0、1 和 2：无 boost、最小和最大 foreground application boost。

官方 Windows Internals Sixth Edition 示例将该参数描述为一组字段：

位	用途
0-1	foreground boost 程度
2-3	可变或固定时间片
4-5	短或长时间片

0x02 是记录的 client Windows 初始值：它设定最大 foreground boost，而将其余字段留给系统策略。对于客户端 Windows，历史上这对应于短可变时间片，可以显式表示为 0x26。0x1A 在相同的最大 foreground boost 下设定长固定时间片。

开源项目 Win32PSCalculator 直接展示了这种等价性。它通过 0x3F 掩码输入，解析三个两位字段，并将不同记录归约为 12 种规范组合之一。这有助于发现那些看起来不同但不会产生新 scheduler mode 的 placebo 值。

Windows Internals 文档是历史性的。我们用它来解释字段，但不声称所有内部 quantum tables 在所有现代版本中都保持不变。

值计算器

输入在 tweak 列表中找到的值。计算器仅显示使用的六个位及相同模式的规范组合。不会更改计算机上的任何内容。

等效模式0x26

Windows default：在客户端 Windows 上对应显式模式 0x26。

000010

已输入: 0x00000002 · 2
应用掩码 0x3F 后: 0x02 · 2
量子: 系统 default → 短
类型: 系统 default → 可变
前台增强: 最大 · 3:1

计算器仅在浏览器中运行，不读取也不修改 Registry。它的结果展示位组合的等价性，而不是预期的 FPS 或延迟。同一版本可在 BoosterX 设置页面获取。

为什么结果可能取决于负载

调度器在选择就绪线程时会考虑 priority、affinity、状态和剩余 quantum。quantum 耗尽后，线程可能将处理器让给同 priority 的另一个就绪线程。上下文切换有开销，因此较长的时间片能够减少 scheduler turnover，并在 CPU 竞争激烈时维持 throughput。

这解释了效果可能的方向，但并不承诺游戏会获得提升。较长的固定 quantum 同时可能恶化其他线程的响应性。如果 CPU 不是瓶颈，可能没有可测量的收益。

历史测试方法

测试在 Windows 10 22H2 的 Valorant 中进行，记录了 100% CPU 负载。对每个 Registry 值，使用 BoosterX 硬件测试台执行了 300 次 click-to-photon 测量。Logitech G PRO X SUPERLIGHT 按键的电信号启动计时器，光传感器在屏幕亮度变化后停止计时。完整链路见研究方法。

表中保存了 AVG、STDDEV、MIN 和 MAX 延迟。FPS 使用 CapFrameX，但在可用区块中每个配置只有一次 capture。对于部分值，capture 挂起，因此这些 FPS 行标记为不可用，且不通过假设来恢复。

原始 300 个 click samples、P90、分布、精确的 hardware/driver manifest 以及独立的 FPS 重复测试都未与该旧系列关联。这限制了统计结论。

结果

值	策略	AVG, ms	SD, ms	MIN, ms	MAX, ms	FPS AVG	P1	P0.1
`0x2A`	短、固定、高 boost	16.61	2.69	10.53	21.96	351.3	226.2	43.9
`0x29`	短、固定、中 boost	17.08	3.02	10.31	25.09	336.8	254.9	14.3
`0x28`	短、固定、无 boost	17.62	4.94	10.19	47.04	不适用	不适用	不适用
`0x26`	default `0x02` 的显式等价	15.28	3.12	9.30	23.08	334.4	111.6	36.9
`0x25`	短、可变、中 boost	16.90	2.73	11.42	23.97	334.7	102.6	27.6
`0x24`	短、可变、无 boost	18.71	4.66	11.88	32.48	不适用	不适用	不适用
`0x1A`	长、固定、高 boost	15.68	3.31	9.97	23.30	355.1	256.0	41.0
`0x19`	长、固定、中 boost	16.80	2.61	10.08	21.95	352.0	272.9	21.5
`0x18`	长、固定、无 boost	22.74	8.81	11.65	55.10	不适用	不适用	不适用
`0x16`	长、可变、高 boost	16.77	2.88	11.32	23.97	346.4	200.1	34.0
`0x15`	长、可变、中 boost	16.13	2.34	10.08	20.95	332.1	144.4	17.8
`0x14`	长、可变、无 boost	19.87	5.55	12.43	52.31	不适用	不适用	不适用

н/д 表示不可用或缺失的 FPS capture，而不是零结果。

default 与 0x1A 的比较

指标	Default / 等价 `0x26`	`0x1A`	观察到的差异
Click-to-photon AVG	15.28 ms	15.68 ms	`0x1A` 高 0.40 ms，约 2.6%
Click-to-photon SD	3.12 ms	3.31 ms	`0x1A` 高 0.19 ms
FPS AVG	334.4	355.1	`0x1A` 高 20.7，约 6.2%
P1	111.6	256.0	`0x1A` 高 144.4
P0.1	36.9	41.0	`0x1A` 高 4.1

平均延迟差异 0.40 ms 明显小于保存的约 3 ms 离散度。没有原始 samples，就无法正确构建置信区间或检验分布形状。FPS 差异按描述性数字来看很大，但每个状态一次 capture 不能证明可复现性，也不能排除运行顺序或后台负载的影响。

已确认的内容

该参数与 foreground boost 和 Windows 调度器时间片策略相关。
在所研究的 Windows 11 24H2 和 25H2 中观察到了对它的读取。
在历史性的 Windows 10 22H2 系列中，每个值执行了 300 次 click-to-photon 测量。
在高 foreground boost 状态中，default 等价 0x26 显示出最低的平均延迟。
在同一历史 capture 中，0x1A 在高 boost 状态中显示出最高的 FPS AVG 和 P1。

未确认的内容

0x1A 总是提升 FPS、P1 或帧平滑度。
0x1A 降低 click-to-photon 或 input latency。
该结果会在 Windows 11、其他 CPU、其他游戏或非 CPU 满载情况下重复。
来自他人 tweak 列表的任意值有用或安全。
差异具有统计显著性：旧系列没有原始 samples 和独立的 FPS 重复测试。

局限性

历史表格不包含完整关联的硬件 manifest、驱动和游戏版本、温度、power state 以及运行顺序。同一次 capture 的窗口不被视为独立重复。CapFrameX 错误主要影响无 foreground boost 的状态，因此无法比较完整的 FPS 矩阵。

研究和所用工具属于 BoosterX 开发者，而该开发者提供此设置，因此开发者对结果有直接利益。方法和适用范围已在上文描述，结论可通过公开数据和所列公开来源进行验证。因此 default 仍是推荐值，而更高的历史 FPS 0x1A 与平均延迟的负面结果及所有局限性一同发布。

实际结论

在大多数 Windows 10 和 11 客户端系统上保留 Windows default (0x02)。不要将 0x1A 作为通用的“调度器优化”来应用。Windows Server 具有不同的 scheduler policy，未经过测量，也不在本建议范围内。

只有在可复现的 CPU saturation 下，验证 0x1A 才有正当理由。使用多次配对运行，打乱顺序，记录平均 FPS、P1、P0.1、frametime spikes 和 click-to-photon。只有在目标指标可重复改善且没有新的恶化时，才保留该更改。

免费设置页面和精确的还原方式：BoosterX 中的 Win32PrioritySeparation。

恢复状态

比较后，通过 BoosterX 将参数恢复为 Windows default (0x02)，并执行界面建议的重启。在历史数据集中没有保存关于验证还原的单独记录，因此本研究不认为 recovery 是旧实验已确认的一部分。

公开一手来源

Win32_OperatingSystem.ForegroundApplicationBoost，Microsoft Learn - Registry 映射和 foreground boost 值。
CPU Analysis，Microsoft Learn - quantum、priority、processor selection 和 context switches 开销。
Scheduling Priorities，Microsoft Learn - round-robin、preemption 和 dynamic priority。
Context Switches，Microsoft Learn - 切换线程时发生的情况。
Windows Internals Sixth Edition sample chapters，Microsoft Press - 参数字段和客户端时间片的历史描述。
BoosterX click-to-photon 测量公开表格 - 该历史系列已发布的原始聚合数据。
Win32PSCalculator - 解码低六位并查找等价模式的开源实现。

公开来源和表述已核对：2026-08-24。

变更历史

2026-09-20： 利益冲突免责声明加强为完整表述，包含研究和工具的归属。
2026-08-24： 添加了 Registry value 的精确位置、记录的初始值 0x02、Win32PSCalculator 以及对缺失 DWORD 解释的边界。
2026-08-24： 首次发布；添加了完整历史矩阵、机制与用户效果的区分，以及 default 建议。