Win32PrioritySeparation：CPU 滿載時的延遲與 FPS
本頁內容
簡短回答：
Win32PrioritySeparation確實控制 foreground boost 以及部分 CPU 量子政策。我們的歷史測試並未發現普遍最佳的值。Windows 預設顯示出略低的平均 click-to-photon 延遲，而0x1A在 100% CPU 負載下的一次測試中與最佳 FPS 和 P1 相符。由於缺乏獨立的 FPS 重複測試與原始 click samples，我們建議使用預設值，並將0x1A僅視為針對 CPU 情境的可驗證假設。
狀態： 該參數與 foreground boost 的關聯已有 Microsoft 文件記載。在先前收集的 Windows 11 24H2 與 25H2 系統追蹤中觀察到該參數的讀取。使用者效果是在歷史性的 Windows 10 22H2 系列中測量的，但未能在其他系統或獨立執行中重現。
可驗證的主張
Section titled “ 可驗證的主張”我們檢驗了三項不能合併的主張：
- 該參數存在，且與 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 |
| 用戶端 Windows 的文件記載初始值 | 0x02 (2) |
Windows Internals 將 2 稱為用戶端 Windows 以及未設定為 application server 之伺服器上的初始值。在我們的 Windows 11 25H2 追蹤中，DWORD 也明確存在，值為 2。
因此我們不認為值的缺失是普遍的 Windows 預設。它可能在映像修改、手動刪除或第三方工具操作後出現，但在目前的研究中，DWORD 缺失的 clean-install 情境並未動態重現。資料列的缺失不能自動解讀為 0。
Microsoft 將 Win32_OperatingSystem.ForegroundApplicationBoost 屬性對應到 Win32PrioritySeparation，並記載了 0、1 與 2 這幾個值：無 boost、最小與最大 boost foreground application。
官方的 Windows Internals Sixth Edition 範例將該參數描述為一組欄位：
| 位元 | 用途 |
|---|---|
| 0-1 | foreground boost 的程度 |
| 2-3 | 可變或固定量子 |
| 4-5 | 短或長量子 |
0x02 是文件記載的用戶端 Windows 初始值：它設定最大 foreground boost，並將其餘欄位留給系統政策。對用戶端 Windows 而言，歷史上這對應於短的可變量子，可明確表示為 0x26。0x1A 在相同的最大 foreground boost 下設定長的固定量子。
開放原始碼專案 Win32PSCalculator 直接展示了這種等價性。它透過 0x3F 遮罩輸入，解析三個兩位元欄位，並將不同的寫法歸納為 12 種標準組合之一。這有助於發現那些看起來不同但不會產生新 scheduler mode 的 placebo 值。
Windows Internals 文件是歷史性的。我們用它來解讀欄位，但並不主張所有內部 quantum tables 在所有現代組建中都保持不變。
6 位元解碼器
實際模式檢查
輸入您在 tweak 清單中找到的值。計算機只會顯示使用的六個位元及具有相同模式的標準組合。它不會變更電腦上的任何設定。
計算器僅在瀏覽器中運作，不會讀取或修改 Registry。其結果顯示位元組合的等價性，而非預期的 FPS 或延遲。同一版本可在 BoosterX 設定頁面 取得。
為何結果可能取決於負載
Section titled “ 為何結果可能取決於負載”排程器在選擇就緒執行緒時，會考量 priority、affinity、狀態與剩餘的 quantum。quantum 用盡後，執行緒可能讓出處理器給同 priority 的另一個就緒執行緒。切換 context 有成本，因此較長的量子可能減少 scheduler turnover，並在 CPU 競爭激烈時維持 throughput。
這解釋了效果可能的方向，但並不保證遊戲能獲得提升。較長的固定 quantum 同時可能降低其他執行緒的回應性。若 CPU 不是瓶頸，可能不會有可測量的收益。
歷史測試的方法
Section titled “ 歷史測試的方法”測試在 Windows 10 22H2 的 Valorant 中進行，記錄的 CPU 負載為 100%。對每個 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 |
預設 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，而非零結果。
預設與 0x1A 的比較
Section titled “預設與 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，無法證明可重現性，也無法排除執行順序或背景負載的影響。
已證實的事項
Section titled “ 已證實的事項”- 該參數與 foreground boost 及 Windows 排程器的量子政策相關。
- 在所研究的 Windows 11 24H2 與 25H2 中觀察到其讀取。
- 在歷史性的 Windows 10 22H2 系列中，對每個值執行了 300 次 click-to-photon 測量。
- 在具有高 foreground boost 的狀態中，預設等價的
0x26顯示出最低的平均延遲。 - 在同一歷史 capture 中，
0x1A在高 boost 狀態中顯示出最高的 FPS AVG 與 P1。
未證實的事項
Section titled “ 未證實的事項”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 開發者，而該開發者提供此設定，因此開發者對結果有直接利益。方法與適用範圍已於上文描述，結論可依公開資料與所列公開來源查驗。因此預設值仍是建議，而較高的歷史 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 視為舊實驗已證實的一部分。
公開主要來源
Section titled “ 公開主要來源”- Win32_OperatingSystem.ForegroundApplicationBoost，Microsoft Learn - Registry mapping 與 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： 首次發表；新增完整歷史矩陣、機制與使用者效果的區分，以及預設值建議。