Pular para o conteúdo

SystemResponsiveness e MMCSS: o que fazem os valores 0, 10, 20 e 100

Nesta página

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.

Página prática de configuração: «Reserva de CPU para tarefas em segundo plano».

O estudo verificou três afirmações distintas:

  1. Se 0, 10, 20, 100 e o valor ausente alteram o estado efetivo do MMCSS após o arranque.
  2. Se 10 oferece uma vantagem praticamente significativa sobre 20 no p99 da latência da workload sintética do MMCSS com o CPU totalmente carregado.
  3. 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.

  • 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, 20 e 100.
  • Verificação adicional de limites: 1, 9, 11, 19, 21, 99, 101 e 0xFFFFFFFF.
  • 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.

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, Playback e 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.

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.

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.

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.

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.

  • SystemResponsiveness altera o estado observável do MMCSS após o arranque do Windows.
  • 0 não cria um estado efetivo 0, mas é normalizado para 20.
  • 10 e 20 permitem o registo do thread e neste teste produzem a mesma transição da sua prioridade.
  • Não foi estabelecida uma vantagem praticamente significativa de 10 sobre 20 na métrica p99 escolhida.
  • 100 desativa 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.
  • Que 10 e 20 sejam equivalentes para todas as workload do MMCSS.
  • Que 10 aumente os FPS, reduza a input latency ou melhore o áudio.
  • Que 100 provoque 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.

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.

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.

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 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.

  • 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.