SystemResponsiveness 與 MMCSS：數值 0、10、20 和 100 的作用
本頁內容
在 BoosterX 中，此參數以「SystemResponsiveness」設定呈現。值 10 會改變 MMCSS 保留量，但在已驗證的情境中並未確立其相對 20 的優勢；100 會停用 MMCSS。
SystemResponsiveness 並非安慰劑。這是 MMCSS 參數，Windows 會在載入時將其正規化並套用。在受研究的 Windows 11 中，值 0 產生了相同的有效狀態 20，而 10 改變了 MMCSS 狀態，但在排程器合成測試中未顯示出相對 20 的優勢。
值 100 停用了 MMCSS。執行緒註冊未執行，執行緒未獲得優先順序提升，而合成排程 workload 的 p99 延遲相對於 20 上升了約 11-12 ms。此結果並不表示 Windows 整體變慢了 60%，也不證明 FPS、input latency 或實際音訊的惡化。
相關的 BoosterX 設定
Section titled “相關的 BoosterX 設定”實用設定頁面：「背景工作的 CPU 保留量」。
可驗證的陳述
Section titled “ 可驗證的陳述”本研究檢驗了三項獨立的陳述：
0、10、20、100以及缺失值是否會改變載入後 MMCSS 的實際狀態。- 在 CPU 滿載下，
10是否在合成 MMCSS workload 的 p99 延遲上相對20具有實務上顯著的優勢。 - 停用 MMCSS 時的結果是否可由已註冊執行緒失去優先順序提升來解釋。
即使機制與合成指標的變化獲得確認，也不證明其對使用者延遲、音訊或遊戲效能有影響。
- Windows 11 Pro 25H2 x64，build
26200.9168。 - VMware VM：4 vCPU、8 GB RAM、電源計畫 Balanced。
- 主要狀態：缺失值、
0、10、20與100。 - 額外的邊界檢查：
1、9、11、19、21、99、101與0xFFFFFFFF。 - 結果僅適用於單一虛擬機器與單一 Windows 組建。
組建由 Microsoft Support 的更新頁面 KB5121003 確認。
Microsoft 記載的內容
Section titled “ Microsoft 記載的內容”Microsoft 將 MMCSS 描述為一種機制，讓 time-sensitive multimedia workload 能優先取得 CPU 存取權，而不會完全排擠較低優先順序的工作。參數 SystemResponsiveness 儲存於 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile。
在 MMCSS 文件 中指出：
- 非 10 的倍數的值會向下捨入至最接近的十位數；
- 低於 10 及高於 100 的值會被調整為 20；
- 值 100 會停用 MMCSS；
Games、Audio、Playback及其他設定檔皆為 MMCSS 工作。
應用程式透過 AvSetMmThreadCharacteristics 將目前執行緒與工作關聯，透過 AvSetMmThreadPriority 變更相對優先順序，並透過 AvRevertMmThreadCharacteristics 取消註冊。
文件並未規定缺失 Registry value 的行為。其下方結果僅為針對已驗證組建的觀察。
主要指標為在四個 vCPU 滿載下，設定檔 Games 中週期性工作啟動延遲的 p99。一次獨立執行對應於一次獨立 Windows 載入後的一種狀態。每次執行內執行 2500 個週期，但這些週期不被視為獨立的重复。
針對每種狀態進行了兩組各 10 次載入的系列。狀態順序經過平衡，離群值未被移除。實務上顯著的閾值事先設定為 1.784 ms。對於與狀態 20 的差異，使用了配對 bootstrap 95% CI。
兩個系列分別呈現：第二個系列中有一個額外的 validation-only ETW 工作階段，而第一個系列中沒有。它不是主要指標的來源，但第二個區塊較為嘈雜，因此合併 20 次執行的數字可能會掩蓋資料的非均勻性。
獨立的機制檢查包含 10、20、100 及缺失值各四次載入。同一執行緒在嘗試 MMCSS 註冊之前、之後以及 cleanup 之後進行測量。檢查了註冊結果、Win32 thread priority 以及透過 ETW 取得的實際排程器優先順序。全部 16 次主要執行均被接受；此系列中沒有遺失的 ETW events 或 buffers。基礎設施試行未納入結果。
Windows 如何處理這些值
Section titled “Windows 如何處理這些值”| 寫入值 | 載入後觀察到的狀態 | 結果 |
|---|---|---|
| 缺失 | MMCSS 已停止，註冊未執行，API 回傳 100 | 此組建的獨立觀察 |
0, 1, 9 |
API 回傳 20，MMCSS 運作中 | 正規化為 20 |
10 |
API 回傳 10，MMCSS 運作中 | 值被使用 |
11, 19 |
API 回傳 10，MMCSS 運作中 | 向下捨入 |
20 |
API 回傳 20，MMCSS 運作中 | 值被使用 |
21 |
API 回傳 20，MMCSS 運作中 | 向下捨入 |
99 |
API 回傳 90，MMCSS 運作中 | 向下捨入 |
100 |
MMCSS 已停止，註冊未執行 | 已記載的停用 |
101, 0xFFFFFFFF |
API 回傳 20，MMCSS 運作中 | 正規化為 20 |
對於數值，對照表與 Microsoft 文件一致。在缺失 value 的情況下，數字 100 是在沒有有效 MMCSS 註冊的情況下回傳的，因此它被列為 API fallback，而非對運作中 MMCSS 查詢的結果。此組建中的停用狀態已透過服務與註冊分別確認，但不能自動套用至其他 Windows 版本。
新狀態的可靠套用是在重新啟動後觀察到的。變更 Registry 並未改變已開啟的 MMCSS handle 或目前載入中新增程序的狀態。失敗的服務停止與啟動嘗試不被視為受支援的套用方式。
合成延遲的 p99
Section titled “合成延遲的 p99”正差異表示相對於 20 更高（即更差）的 p99 延遲。
與 20 的比較 |
系列 1，差異與 95% CI | 系列 2，差異與 95% CI | 結論 |
|---|---|---|---|
10 |
+0.625 ms [-1.111; +2.474] |
+0.975 ms [-3.579; +5.613] |
優勢未確立；等價性未獲證明 |
0 |
+1.267 ms [-0.014; +2.564] |
-1.902 ms [-4.681; +0.718] |
結果不確定且方向不一致 |
100 |
+10.812 ms [+8.787; +12.915] |
+12.074 ms [+9.669; +14.127] |
合成 proxy 中實務上顯著的危害 |
| 缺失 | +11.640 ms [+9.690; +13.480] |
+12.494 ms [+9.303; +16.208] |
合成 proxy 中實務上顯著的危害 |
10 在任一組系列中均未顯示出相對 20 的實務上顯著優勢。第二組系列的寬區間允許有益或有害兩種可能，因此該結果不能稱為等價性的證明。
停用 MMCSS 時改變了什麼
Section titled “停用 MMCSS 時改變了什麼”| 狀態 | 註冊 | MMCSS 狀態 | 單一執行緒的 Win32 priority | 單一執行緒的 ETW priority |
|---|---|---|---|---|
20 |
4/4 | 運作中 | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
10 |
4/4 | 運作中 | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
100 |
0/4 | 已停止 | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
| 缺失 | 0/4 | 已停止 | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
最後兩欄的序列表示註冊前、嘗試註冊後以及 cleanup 後的狀態。Process priority class 未改變。
這直接確認了合成指標惡化的一項原因：在停用 MMCSS 時，測試執行緒繼續進行相同的工作，但未獲得優先順序提升。CPU quota 及其他資源計量規則的個別貢獻未被隔離。
100 與缺失值在服務狀態、註冊結果及執行緒優先順序上一致。這不證明它們在所有內部與使用者情境中完全等價。
已確認的內容
Section titled “ 已確認的內容”SystemResponsiveness會改變 Windows 載入後觀察到的 MMCSS 狀態。0不會產生有效狀態 0，而是正規化為 20。10與20允許執行緒註冊，且在此測試中產生相同的優先順序轉換。10相對20在所選 p99 指標上實務上顯著的優勢未獲確立。100會停用 MMCSS；在已驗證的組建中，缺失 value 時觀察到相同狀態。- 在停用 MMCSS 時，測試執行緒未獲得優先順序提升，且合成 p99 延遲在兩組系列中均惡化。
未確認的內容
Section titled “ 未確認的內容”10與20對所有 MMCSS workload 皆等價。10能提升 FPS、降低 input latency 或改善音訊。100必然導致 audio glitches、不同步或特定遊戲中的問題。- 缺失 value 的觀察會在其他 Windows 組建上重現。
- 所得到的毫秒數為實體 end-to-end latency。
- 虛擬機器的結果可套用至實體 PC。
本研究在一台 VMware VM 與一個 Windows 組建上完成。合成設定檔 Games 建立了可控的 CPU 競爭，但未重現遊戲引擎、音訊驅動程式、實際 input pipeline 或 display scanout。
在第二組系列中，額外的 ETW 工作階段僅用於驗證，但可能改變了整體雜訊水準。因此兩組系列未合併為單一估計。機制檢查顯示了優先順序提升的喪失，但未分離 MMCSS quota 與 accounting policy 的可能貢獻。
實體音訊測試、FPS、frametime、click-to-photon 及 input latency 均未測量。目前尚無在其他機器或組建上的獨立重現。
不要使用 0 作為設定「零保留量」的方式：Windows 會將其調整為 20。不要將 10 視為已證明較佳的通用值：在此 VM 中，相對 20 的優勢未獲確立。
不要使用 100，也不要為了「停用限制」而刪除該值。在已驗證的環境中，這停用了 MMCSS、使執行緒失去優先順序提升，並明顯惡化了合成 p99 延遲。若無獨立的實體測試，不能將此結論轉化為對 FPS 或音訊的精確預測。
對於一般系統，安全的結論僅限於維持 Windows 的預設狀態。只有在事先選定使用者指標、重複進行配對測量並確認可還原的情況下，變更才具有正當性。
簡要的使用者建議與確切的登錄狀態已發布於 「SystemResponsiveness」 頁面。
在每個實驗階段之後，VM 都會回到受保護的初始狀態。對照載入確認了 Registry value 20、MMCSS 運作中、無作用中的追蹤以及測試程序已結束。驗證後再次執行還原，VM 保持關機。
公開的一手來源
Section titled “ 公開的一手來源”- Multimedia Class Scheduler Service，Microsoft Learn - MMCSS 的用途、
SystemResponsiveness、捨入以及值為 100 時的停用。 - AvSetMmThreadCharacteristicsW，Microsoft Learn - 將目前執行緒註冊至 MMCSS 工作。
- AvSetMmThreadPriority，Microsoft Learn - 已註冊執行緒的相對優先順序。
- AvRevertMmThreadCharacteristics，Microsoft Learn - 結束執行緒註冊。
- KB5121003，Microsoft Support - Windows 11 build
26200.9168。
公開來源與措辭已驗證：2026-08-25。
本研究及所使用的工具屬於 BoosterX 開發者，因此開發者對結果有直接利益。方法與適用範圍已於上文說明，且結論可透過公開資料及所列的公開來源進行驗證。產品中存在該參數並未被用作證據；10 的不確定結果以及停用 MMCSS 的負面結果均未經篩選地保留。
BoosterX Wiki 為獨立出版物，與 Microsoft Corporation 無關聯、未經其授權、贊助或認可。
- 2026-09-20： 利益衝突免責聲明強化為完整措辭，載明研究與工具的歸屬。
- 2026-08-25： 首次發布；新增兩組分開的 p99 系列、執行緒優先順序檢查、音訊與遊戲的適用範圍，以及已確認的狀態還原。