SystemResponsiveness e MMCSS: o que fazem os valores 0, 10, 20 e 100
Nesta página
Resposta curta
Seção intitulada “ Resposta curta”No BoosterX, este parâmetro está representado pela definição «SystemResponsiveness». O valor 10 altera a reserva do MMCSS, mas não foi estabelecida qualquer vantagem sobre 20 no cenário testado; 100 desativa o MMCSS.
SystemResponsiveness não é um placebo. É um parâmetro do MMCSS que o Windows normaliza e aplica durante o arranque. No Windows 11 investigado, o valor 0 produziu o mesmo estado efetivo 20, e 10 alterou o estado do MMCSS, mas não mostrou vantagem sobre 20 no teste sintético do agendador.
O valor 100 desativou o MMCSS. O registo do thread não foi efetuado, o thread não recebeu aumento de prioridade, e o p99 da latência da workload sintética de agendamento aumentou cerca de 11-12 ms em relação a 20. Este resultado não significa que o Windows no seu todo ficou 60% mais lento, nem prova deterioração de FPS, input latency ou áudio real.
Definições relacionadas do BoosterX
Seção intitulada “Definições relacionadas do BoosterX”Página prática de configuração: «Reserva de CPU para tarefas em segundo plano».
Afirmação verificável
Seção intitulada “ Afirmação verificável”O estudo verificou três afirmações distintas:
- Se
0,10,20,100e o valor ausente alteram o estado efetivo do MMCSS após o arranque. - Se
10oferece uma vantagem praticamente significativa sobre20no p99 da latência da workload sintética do MMCSS com o CPU totalmente carregado. - Se o resultado com o MMCSS desativado se explica pela perda do aumento de prioridade do thread registado.
Mesmo uma alteração confirmada do mecanismo e da métrica sintética não prova impacto na latência do utilizador, no áudio ou no desempenho em jogos.
Âmbito do estudo
Seção intitulada “ Âmbito do estudo”- Windows 11 Pro 25H2 x64, build
26200.9168. - VMware VM: 4 vCPU, 8 GB RAM, plano de energia Balanced.
- Estados principais: valor ausente,
0,10,20e100. - Verificação adicional de limites:
1,9,11,19,21,99,101e0xFFFFFFFF. - O resultado refere-se a uma única máquina virtual e a uma única build do Windows.
A build é confirmada pela página de atualização KB5121003 do Microsoft Support.
O que a Microsoft documenta
Seção intitulada “ O que a Microsoft documenta”A Microsoft descreve o MMCSS como um mecanismo que permite a workload multimédia time-sensitive obter acesso prioritário ao CPU sem desalojar por completo trabalho de prioridade mais baixa. O parâmetro SystemResponsiveness está armazenado em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.
Na documentação do MMCSS indica-se:
- valores que não sejam múltiplos de 10 são arredondados para baixo até à dezena mais próxima;
- valores abaixo de 10 e acima de 100 são convertidos em 20;
- o valor 100 desativa o MMCSS;
Games,Audio,Playbacke outros perfis são tarefas do MMCSS.
A aplicação associa o thread atual a uma tarefa através de AvSetMmThreadCharacteristics, altera a prioridade relativa através de AvSetMmThreadPriority e anula o registo através de AvRevertMmThreadCharacteristics.
A documentação não define o comportamento do valor de Registry ausente. O seu resultado abaixo é uma observação apenas para a build testada.
Metodologia
Seção intitulada “ Metodologia”A métrica principal é o p99 da latência de arranque de trabalho periódico no perfil Games com os quatro vCPU totalmente carregados. Uma execução independente correspondia a um estado após um arranque separado do Windows. Dentro de cada execução realizaram-se 2500 períodos, mas estes não foram considerados repetições independentes.
Para cada estado realizaram-se duas séries de 10 arranques. A ordem dos estados foi balanceada, os outliers não foram removidos. O limiar praticamente significativo foi estabelecido antecipadamente em 1.784 ms. Para a diferença em relação ao estado 20 utilizou-se um bootstrap emparelhado com IC de 95%.
As séries são apresentadas separadamente: na segunda série estava ativa uma sessão ETW adicional apenas de validação, que não existia na primeira. Não foi a fonte da métrica principal, mas o segundo bloco revelou-se mais ruidoso, pelo que o número combinado de 20 execuções poderia ocultar a heterogeneidade dos dados.
A verificação separada do mecanismo incluiu quatro arranques para 10, 20, 100 e o valor ausente. O mesmo thread foi medido antes da tentativa de registo no MMCSS, depois desta e após a cleanup. Verificaram-se o resultado do registo, a Win32 thread priority e a prioridade efetiva do agendador por ETW. Todas as 16 execuções principais foram aceites; não houve perda de ETW events ou buffers nesta série. Os pilotos de infraestrutura não foram incluídos nos resultados.
Resultados
Seção intitulada “ Resultados”Como o Windows processou os valores
Seção intitulada “Como o Windows processou os valores”| Registado | Estado observado após o arranque | Resultado |
|---|---|---|
| ausente | MMCSS parado, registo não efetuado, API devolveu 100 | observação separada para esta build |
0, 1, 9 |
API devolveu 20, MMCSS em funcionamento | normalizado para 20 |
10 |
API devolveu 10, MMCSS em funcionamento | valor utilizado |
11, 19 |
API devolveu 10, MMCSS em funcionamento | arredondado para baixo |
20 |
API devolveu 20, MMCSS em funcionamento | valor utilizado |
21 |
API devolveu 20, MMCSS em funcionamento | arredondado para baixo |
99 |
API devolveu 90, MMCSS em funcionamento | arredondado para baixo |
100 |
MMCSS parado, registo não efetuado | desativação documentada |
101, 0xFFFFFFFF |
API devolveu 20, MMCSS em funcionamento | normalizado para 20 |
Para os valores numéricos, o mapa coincidiu com a documentação da Microsoft. Com o value ausente, o número 100 foi devolvido sem um registo válido no MMCSS, pelo que é indicado como API fallback e não como resultado de um pedido a um MMCSS em funcionamento. O estado desativado nesta build foi confirmado separadamente pelo serviço e pelo registo, mas não pode ser automaticamente transposto para outras versões do Windows.
A aplicação fiável do novo estado foi observada após reinício. A alteração do Registry não mudou o estado de um handle do MMCSS já aberto nem de um novo processo no arranque atual. Uma tentativa falhada de parar e iniciar o serviço não é considerada um método de aplicação suportado.
p99 da latência sintética
Seção intitulada “p99 da latência sintética”Uma diferença positiva significa uma p99 de latência mais elevada, ou seja, pior, em relação a 20.
Comparação com 20 |
Série 1, diferença e IC de 95% | Série 2, diferença e IC de 95% | Conclusão |
|---|---|---|---|
10 |
+0.625 ms [-1.111; +2.474] |
+0.975 ms [-3.579; +5.613] |
vantagem não estabelecida; equivalência não provada |
0 |
+1.267 ms [-0.014; +2.564] |
-1.902 ms [-4.681; +0.718] |
resultado indefinido e divergente em direção |
100 |
+10.812 ms [+8.787; +12.915] |
+12.074 ms [+9.669; +14.127] |
prejuízo praticamente significativo no proxy sintético |
| ausente | +11.640 ms [+9.690; +13.480] |
+12.494 ms [+9.303; +16.208] |
prejuízo praticamente significativo no proxy sintético |
10 não mostrou uma vantagem praticamente significativa sobre 20 em nenhuma das séries. O intervalo amplo da segunda série admite tanto benefício como prejuízo, pelo que o resultado não pode ser apresentado como prova de equivalência.
O que mudou com o MMCSS desativado
Seção intitulada “O que mudou com o MMCSS desativado”| Estado | Registo | Estado do MMCSS | Win32 priority de um thread | ETW priority de um thread |
|---|---|---|---|---|
20 |
4/4 | em funcionamento | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
10 |
4/4 | em funcionamento | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
100 |
0/4 | parado | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
| ausente | 0/4 | parado | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
A sequência nas duas últimas colunas significa o estado antes do registo, após a tentativa de registo e após a cleanup. A Process priority class não mudou.
Isto confirma diretamente uma causa da deterioração da métrica sintética: com o MMCSS desativado, o thread de teste continuou o mesmo trabalho, mas não recebeu o aumento de prioridade. A contribuição separada da CPU quota e de outras regras de contabilização de recursos não foi isolada.
100 e o valor ausente coincidiram no estado do serviço, no resultado do registo e na prioridade do thread. Isto não prova a sua equivalência total em todos os cenários internos e de utilizador.
O que foi confirmado
Seção intitulada “ O que foi confirmado”SystemResponsivenessaltera o estado observável do MMCSS após o arranque do Windows.0não cria um estado efetivo 0, mas é normalizado para 20.10e20permitem o registo do thread e neste teste produzem a mesma transição da sua prioridade.- Não foi estabelecida uma vantagem praticamente significativa de
10sobre20na métrica p99 escolhida. 100desativa o MMCSS; na build testada, o mesmo estado foi observado com o value ausente.- Com o MMCSS desativado, o thread de teste não recebeu o aumento de prioridade, e a p99 da latência sintética piorou em ambas as séries.
O que não foi confirmado
Seção intitulada “ O que não foi confirmado”- Que
10e20sejam equivalentes para todas as workload do MMCSS. - Que
10aumente os FPS, reduza a input latency ou melhore o áudio. - Que
100provoque obrigatoriamente audio glitches, dessincronização ou problemas num jogo específico. - Que a observação para o value ausente se repita noutra build do Windows.
- Que os milissegundos obtidos sejam latência física end-to-end.
- Que o resultado da máquina virtual seja transponível para um PC físico.
Limitações
Seção intitulada “ Limitações”O estudo foi realizado numa única VMware VM e numa única build do Windows. O perfil sintético Games cria uma concorrência controlada pelo CPU, mas não reproduz um motor de jogo, um controlador de áudio, um input pipeline real ou o display scanout.
Na segunda série, a sessão ETW adicional foi usada apenas para validação, mas pode ter alterado o nível geral de ruído. Por isso, as duas séries não foram combinadas numa única estimativa. A verificação do mecanismo mostra a perda do aumento de prioridade, mas não separa a possível contribuição da MMCSS quota e da accounting policy.
Não foram medidos testes de áudio físicos, FPS, frametime, click-to-photon nem input latency. Ainda não existe uma repetição independente noutra máquina ou build.
Conclusão prática
Seção intitulada “ Conclusão prática”Não use 0 como forma de definir uma «reserva zero»: o Windows converte-o em 20. Não considere 10 como um valor universal comprovadamente melhor: nesta VM não foi estabelecida qualquer vantagem sobre 20.
Não use 100 nem elimine o valor para «desativar restrições». No ambiente testado, isto desativou o MMCSS, retirou ao thread o aumento de prioridade e piorou de forma notória a p99 da latência sintética. Sem um teste físico separado, esta conclusão não pode ser transformada numa previsão exata de FPS ou de áudio.
Para um sistema comum, a conclusão segura limita-se a manter o estado predefinido do Windows. A alteração só se justifica com uma métrica de utilizador escolhida antecipadamente, medições emparelhadas repetidas e um retorno confirmado.
Restauro do estado
Seção intitulada “ Restauro do estado”A recomendação breve para o utilizador e o estado exato do registo estão publicados na página «SystemResponsiveness».
Após cada fase experimental, a VM regressou ao estado inicial protegido. Um arranque de controlo confirmou o Registry value 20, o MMCSS em funcionamento, a ausência de tracing ativo e a conclusão dos processos de teste. Após a verificação, foi feito um novo retorno, e a VM foi deixada desligada.
Fontes primárias públicas
Seção intitulada “ Fontes primárias públicas”- Multimedia Class Scheduler Service, Microsoft Learn - finalidade do MMCSS,
SystemResponsiveness, arredondamento e desativação com 100. - AvSetMmThreadCharacteristicsW, Microsoft Learn - registo do thread atual numa tarefa do MMCSS.
- AvSetMmThreadPriority, Microsoft Learn - prioridade relativa de um thread registado.
- AvRevertMmThreadCharacteristics, Microsoft Learn - conclusão do registo do thread.
- KB5121003, Microsoft Support - Windows 11 build
26200.9168.
Fontes públicas e formulações verificadas: 2026-08-25.
O estudo e as ferramentas utilizadas pertencem ao programador do BoosterX, pelo que o programador tem um interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas através dos dados abertos e das fontes públicas enumeradas. A presença do parâmetro no produto não foi usada como prova; o resultado indefinido para 10 e o resultado negativo da desativação do MMCSS foram mantidos sem seleção.
O BoosterX Wiki é uma publicação independente e não está associado, autorizado, patrocinado ou aprovado pela Microsoft Corporation.
Histórico de alterações
Seção intitulada “Histórico de alterações”- 2026-09-20: o aviso de conflito de interesses foi reforçado para a formulação completa com a pertença do estudo e das ferramentas.
- 2026-08-25: primeira publicação; adicionadas duas séries separadas de p99, a verificação da prioridade do thread, os limites para áudio e jogos, bem como o restauro confirmado do estado.
