SystemResponsiveness and MMCSS: what the values 0, 10, 20 and 100 do

On this page

Short answer

In BoosterX this parameter is exposed as the “SystemResponsiveness” setting. The value 10 changes the MMCSS reserve, but an advantage over 20 was not established in the tested scenario; 100 disables MMCSS.

SystemResponsiveness is not a placebo. It is an MMCSS parameter that Windows normalizes and applies at boot. On the Windows 11 build studied, the value 0 produced the same effective state as 20, and 10 changed the MMCSS state but showed no advantage over 20 in the synthetic scheduler test.

The value 100 disabled MMCSS. Thread registration did not occur, the thread received no priority boost, and the p99 latency of the synthetic scheduling workload increased by roughly 11-12 ms relative to 20. This result does not mean Windows as a whole became 60% slower, and it does not prove a degradation in FPS, input latency or real-world audio.

Practical settings page: “CPU reserve for background tasks”.

Testable claim

The study tested three separate claims:

Whether 0, 10, 20, 100 and a missing value change the actual MMCSS state after boot.
Whether 10 provides a practically significant advantage over 20 in p99 latency of the synthetic MMCSS workload under full CPU load.
Whether the result with MMCSS disabled is explained by the loss of the priority boost for a registered thread.

Even a confirmed change in the mechanism and in the synthetic metric does not prove an effect on user-perceived latency, audio or game performance.

Scope of the study

Windows 11 Pro 25H2 x64, build 26200.9168.
VMware VM: 4 vCPU, 8 GB RAM, Balanced power plan.
Main states: missing value, 0, 10, 20 and 100.
Additional boundary checks: 1, 9, 11, 19, 21, 99, 101 and 0xFFFFFFFF.
The result applies to one virtual machine and one Windows build.

The build is confirmed by the update page KB5121003 on Microsoft Support.

What Microsoft documents

Microsoft describes MMCSS as a mechanism that allows time-sensitive multimedia workload to get prioritized access to the CPU without fully preempting lower-priority work. The SystemResponsiveness parameter is stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

The MMCSS documentation states:

values that are not multiples of 10 are rounded down to the nearest ten;
values below 10 and above 100 are set to 20;
the value 100 disables MMCSS;
Games, Audio, Playback and other profiles are MMCSS tasks.

An application associates the current thread with a task via AvSetMmThreadCharacteristics, changes the relative priority via AvSetMmThreadPriority and unregisters via AvRevertMmThreadCharacteristics.

The documentation does not define the behavior of a missing Registry value. Its result below is an observation for the tested build only.

Methodology

The main metric is the p99 latency of starting periodic work in the Games profile under full load of four vCPU. One independent run corresponded to one state after a separate Windows boot. Within each run 2500 periods were executed, but they were not counted as independent repetitions.

For each state, two series of 10 boots each were performed. The order of states was balanced, outliers were not removed. The practically significant threshold was set in advance at 1.784 ms. For the difference from the 20 state, a paired bootstrap 95% CI was used.

The series are shown separately: in the second series an additional validation-only ETW session was running, which was not present in the first. It was not the source of the main metric, but the second block turned out to be noisier, so a combined figure of 20 runs could have hidden heterogeneity in the data.

A separate mechanism check included four boots each for 10, 20, 100 and the missing value. The same thread was measured before the MMCSS registration attempt, after it and after cleanup. The registration result, Win32 thread priority and the actual scheduler priority via ETW were checked. All 16 main runs were accepted; there were no lost ETW events or buffers in this series. Infrastructure pilots were not included in the results.

Results

How Windows handled the values

Written	Observed state after boot	Result
missing	MMCSS stopped, registration not performed, API returned 100	separate observation for this build
`0`, `1`, `9`	API returned 20, MMCSS running	normalized to 20
`10`	API returned 10, MMCSS running	value is used
`11`, `19`	API returned 10, MMCSS running	rounded down
`20`	API returned 20, MMCSS running	value is used
`21`	API returned 20, MMCSS running	rounded down
`99`	API returned 90, MMCSS running	rounded down
`100`	MMCSS stopped, registration not performed	documented disabling
`101`, `0xFFFFFFFF`	API returned 20, MMCSS running	normalized to 20

For numeric values the map matched Microsoft documentation. With a missing value, the number 100 was returned without a valid MMCSS registration, so it is listed as an API fallback rather than as the result of a query to a running MMCSS. The disabled state on this build was confirmed separately by the service and by registration, but it cannot be automatically carried over to other Windows versions.

Reliable application of a new state was observed after a reboot. Changing the Registry did not change the state of an already open MMCSS handle or of a new process in the current boot. An unsuccessful attempt to stop and start the service is not considered a supported way of applying it.

p99 of synthetic latency

A positive difference means higher, that is worse, p99 latency relative to 20.

Comparison with `20`	Series 1, difference and 95% CI	Series 2, difference and 95% CI	Conclusion
`10`	`+0.625 ms` `[-1.111; +2.474]`	`+0.975 ms` `[-3.579; +5.613]`	advantage not established; equivalence not proven
`0`	`+1.267 ms` `[-0.014; +2.564]`	`-1.902 ms` `[-4.681; +0.718]`	result indeterminate and differs in direction
`100`	`+10.812 ms` `[+8.787; +12.915]`	`+12.074 ms` `[+9.669; +14.127]`	practically significant harm in the synthetic proxy
missing	`+11.640 ms` `[+9.690; +13.480]`	`+12.494 ms` `[+9.303; +16.208]`	practically significant harm in the synthetic proxy

10 showed no practically significant advantage over 20 in either series. The wide interval of the second series allows both benefit and harm, so the result cannot be called proof of equivalence.

What changed when MMCSS was disabled

State	Registration	MMCSS state	Win32 priority of one thread	ETW priority of one thread
`20`	4/4	running	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`10`	4/4	running	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`100`	0/4	stopped	`0 -> 0 -> 0`	`8 -> 8 -> 8`
missing	0/4	stopped	`0 -> 0 -> 0`	`8 -> 8 -> 8`

The sequence in the last two columns means the state before registration, after the registration attempt and after cleanup. The Process priority class did not change.

This directly confirms one cause of the degradation in the synthetic metric: with MMCSS disabled, the test thread continued the same work but received no priority boost. The separate contribution of CPU quota and other resource accounting rules was not isolated.

100 and the missing value matched in service state, registration result and thread priority. This does not prove their full equivalence in all internal and user-facing scenarios.

What is confirmed

SystemResponsiveness changes the observed MMCSS state after a Windows boot.
0 does not create an effective state of 0, but is normalized to 20.
10 and 20 allow thread registration and in this test produce the same transition of its priority.
A practically significant advantage of 10 over 20 on the chosen p99 metric was not established.
100 disables MMCSS; on the tested build the same state was observed with a missing value.
With MMCSS disabled, the test thread received no priority boost, and the synthetic p99 latency worsened in both series.

What is not confirmed

That 10 and 20 are equivalent for all MMCSS workload.
That 10 raises FPS, reduces input latency or improves audio.
That 100 necessarily causes audio glitches, desynchronization or problems in a specific game.
That the observation for a missing value repeats on another Windows build.
That the resulting milliseconds are physical end-to-end latency.
That the virtual machine result carries over to a physical PC.

Limitations

The study was performed on one VMware VM and one Windows build. The synthetic Games profile creates controlled CPU contention, but does not reproduce a game engine, an audio driver, a real input pipeline or display scanout.

In the second series, the additional ETW session was used only for validation, but it could have changed the overall noise level. Therefore the two series are not combined into a single estimate. The mechanism check shows the loss of the priority boost, but does not separate the possible contribution of MMCSS quota and accounting policy.

Physical audio testing, FPS, frametime, click-to-photon and input latency were not measured. There is no independent replication on another machine or build yet.

Practical conclusion

Do not use 0 as a way to set a “zero reserve”: Windows sets it to 20. Do not treat 10 as a proven better universal value: on this VM an advantage over 20 was not established.

Do not use 100 and do not delete the value in order to “disable limits”. In the tested environment this disabled MMCSS, deprived the thread of the priority boost and noticeably worsened the synthetic p99 latency. Without a separate physical test, this conclusion cannot be turned into an exact prediction of FPS or audio.

For an ordinary system, the safe conclusion is limited to keeping the default Windows state. A change is justified only with a user metric chosen in advance, repeated paired measurements and a confirmed rollback.

Restoring the state

A brief user recommendation and the exact registry state are published on the “SystemResponsiveness” page.

After each experimental phase the VM was returned to a protected initial state. A control boot confirmed the Registry value 20, a running MMCSS, no active tracing and the termination of test processes. After the check, another rollback was performed, and the VM was left powered off.

Public primary sources

Multimedia Class Scheduler Service, Microsoft Learn - purpose of MMCSS, SystemResponsiveness, rounding and disabling at 100.
AvSetMmThreadCharacteristicsW, Microsoft Learn - registering the current thread with an MMCSS task.
AvSetMmThreadPriority, Microsoft Learn - relative priority of a registered thread.
AvRevertMmThreadCharacteristics, Microsoft Learn - ending thread registration.
KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Public sources and wording verified: 2026-08-25.

The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and the limits of applicability are described above, and the conclusions can be verified against the open data and the public sources listed. The presence of the parameter in the product was not used as evidence; the indeterminate result for 10 and the negative result of disabling MMCSS are preserved without selection.

BoosterX Wiki is an independent publication and is not affiliated with, authorized, sponsored or endorsed by Microsoft Corporation.

Change history

2026-09-20: the conflict-of-interest disclaimer was strengthened to the full wording with ownership of the study and tools.
2026-08-25: first publication; two separate p99 series, a thread priority check, boundaries for audio and games, and a confirmed state restoration were added.