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

Resposta curta

No BoosterX, esse parâmetro é representado pela configuração “SystemResponsiveness”. O valor 10 altera a reserva do MMCSS, mas a vantagem sobre 20 no cenário testado não foi estabelecida; 100 desativa o MMCSS.

SystemResponsiveness não é placebo. É um parâmetro do MMCSS que o Windows normaliza e aplica na inicialização. No Windows 11 pesquisado, 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 registro do thread não foi realizado, o thread não recebeu aumento de prioridade, e o p99 da latência do workload sintético de agendamento aumentou cerca de 11-12 ms em relação a 20. Esse resultado não significa que o Windows como um todo ficou 60% mais lento, e não prova deterioração de FPS, input latency ou áudio real.

Configurações relacionadas do BoosterX

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

Afirmação verificável

A pesquisa verificou três afirmações separadas:

1. Se 0, 10, 20, 100 e o valor ausente alteram o estado efetivo do MMCSS após a inicialização.
2. Se 10 oferece uma vantagem praticamente significativa sobre 20 no p99 da latência do workload sintético do MMCSS sob carga total de CPU.
3. Se o resultado com o MMCSS desativado se explica pela perda do aumento de prioridade do thread registrado.

Mesmo uma alteração confirmada do mecanismo e da métrica sintética não prova impacto na latência do usuário, no áudio ou no desempenho em jogos.

Escopo da pesquisa

• 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 se refere 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

A Microsoft descreve o MMCSS como um mecanismo que permite que workload multimídia time-sensitive obtenha acesso prioritário à CPU sem deslocar completamente o trabalho de prioridade mais baixa. O parâmetro SystemResponsiveness fica armazenado em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

Na documentação do MMCSS consta:

• valores não múltiplos de 10 são arredondados para baixo até a dezena mais próxima;
• valores abaixo de 10 e acima de 100 são ajustados para 20;
• o valor 100 desativa o MMCSS;
• Games, Audio, Playback e outros perfis são tarefas do MMCSS.

O aplicativo associa o thread atual a uma tarefa por meio de AvSetMmThreadCharacteristics, altera a prioridade relativa por meio de AvSetMmThreadPriority e remove o registro por meio de AvRevertMmThreadCharacteristics.

A documentação não define o comportamento do Registry value ausente. O resultado abaixo é uma observação apenas para a build testada.

Metodologia

A métrica principal é o p99 da latência de início de trabalho periódico no perfil Games sob carga total dos quatro vCPU. Uma execução independente correspondia a um estado após uma inicialização separada do Windows. Dentro de cada execução eram realizados 2500 períodos, mas eles não foram considerados repetições independentes.

Para cada estado foram realizadas duas séries de 10 inicializações. A ordem dos estados foi balanceada, outliers não foram removidos. O limiar praticamente significativo foi estabelecido previamente em 1.784 ms. Para a diferença em relação ao estado 20 foi usado bootstrap pareado com IC de 95%.

As séries são mostradas separadamente: na segunda série havia uma sessão ETW adicional apenas de validação, que não existia na primeira. Ela não foi a fonte da métrica principal, mas o segundo bloco se mostrou mais ruidoso, então o número combinado de 20 execuções poderia ocultar a heterogeneidade dos dados.

A verificação separada do mecanismo incluiu quatro inicializações para 10, 20, 100 e o valor ausente. O mesmo thread foi medido antes da tentativa de registro no MMCSS, depois dela e após o cleanup. Foram verificados o resultado do registro, a Win32 thread priority e a prioridade efetiva do agendador por ETW. Todas as 16 execuções principais foram aceitas; não houve perda de ETW events ou buffers nessa série. Pilotos de infraestrutura não foram incluídos nos resultados.

Resultados

Como o Windows tratou os valores

Gravado	Estado observado após a inicialização	Resultado
ausente	MMCSS parado, registro não realizado, API retornou 100	observação separada para esta build
0, 1, 9	API retornou 20, MMCSS em execução	normalizado para 20
10	API retornou 10, MMCSS em execução	valor utilizado
11, 19	API retornou 10, MMCSS em execução	arredondado para baixo
20	API retornou 20, MMCSS em execução	valor utilizado
21	API retornou 20, MMCSS em execução	arredondado para baixo
99	API retornou 90, MMCSS em execução	arredondado para baixo
100	MMCSS parado, registro não realizado	desativação documentada
101, 0xFFFFFFFF	API retornou 20, MMCSS em execução	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 retornou sem registro válido no MMCSS, por isso ele é indicado como API fallback, e não como resultado de uma consulta a um MMCSS em execução. O estado desativado nesta build foi confirmado separadamente pelo serviço e pelo registro, mas não pode ser transferido automaticamente para outras versões do Windows.

A aplicação confiável do novo estado foi observada após a reinicialização. A alteração no Registry não mudou o estado de um MMCSS handle já aberto ou de um novo processo na inicialização atual. Uma tentativa malsucedida de parar e iniciar o serviço não é considerada um modo suportado de aplicação.

p99 da latência sintética

Uma diferença positiva significa uma latência p99 mais alta, 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]	dano praticamente significativo no proxy sintético
ausente	+11.640 ms [+9.690; +13.480]	+12.494 ms [+9.303; +16.208]	dano praticamente significativo no proxy sintético

10 não mostrou vantagem praticamente significativa sobre 20 em nenhuma das séries. O intervalo amplo da segunda série admite tanto benefício quanto dano, por isso o resultado não pode ser chamado de prova de equivalência.

O que mudou com o MMCSS desativado

Estado	Registro	Estado do MMCSS	Win32 priority de um thread	ETW priority de um thread
20	4/4	em execução	0 -> 10 -> 0	8 -> 18 -> 8
10	4/4	em execução	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 registro, após a tentativa de registro e após o cleanup. A Process priority class não mudou.

Isso 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 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 registro e na prioridade do thread. Isso não prova sua equivalência total em todos os cenários internos e de usuário.

O que foi confirmado

• SystemResponsiveness altera o estado observado do MMCSS após a inicialização do Windows.
• 0 não cria o estado efetivo 0, mas é normalizado para 20.
• 10 e 20 permitem o registro do thread e, neste teste, produzem a mesma transição de sua prioridade.
• A vantagem praticamente significativa de 10 sobre 20 pela métrica p99 escolhida não foi estabelecida.
• 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 aumento de prioridade, e a latência p99 sintética piorou em ambas as séries.

O que não foi confirmado

• Que 10 e 20 são equivalentes para todos os workload do MMCSS.
• Que 10 aumenta o FPS, reduz o input latency ou melhora o áudio.
• Que 100 necessariamente causa audio glitches, dessincronização ou problemas em um jogo específico.
• Que a observação para o value ausente se repete em outra build do Windows.
• Que os milissegundos obtidos são latência física end-to-end.
• Que o resultado da máquina virtual se transfere para um PC físico.

Limitações

A pesquisa foi realizada em uma única VMware VM e uma única build do Windows. O perfil sintético Games cria concorrência controlada pela CPU, mas não reproduz o motor de um jogo, o driver de áudio, o 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 em uma ú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.

Teste físico de áudio, FPS, frametime, click-to-photon e input latency não foram medidos. Ainda não há repetição independente em outra máquina ou build.

Conclusão prática

Não use 0 como forma de definir “reserva zero”: o Windows o ajusta para 20. Não considere 10 como um valor universal comprovadamente melhor: nesta VM, a vantagem sobre 20 não foi estabelecida.

Não use 100 e não remova o valor para “desativar as restrições”. No ambiente testado, isso desativou o MMCSS, privou o thread do aumento de prioridade e piorou visivelmente a latência p99 sintética. Sem um teste físico separado, essa conclusão não pode ser transformada em uma previsão exata de FPS ou áudio.

Para um sistema comum, a conclusão segura se limita a manter o estado padrão do Windows. A alteração só se justifica com uma métrica de usuário escolhida previamente, medições pareadas repetidas e retorno confirmado.

Restauração do estado

A recomendação resumida para o usuário e o estado exato do registro estão publicados na página “SystemResponsiveness”.

Após cada fase experimental, a VM retornava ao estado inicial protegido. Uma inicialização de controle confirmou o Registry value 20, o MMCSS em execução, a ausência de rastreamento ativo e o encerramento 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

• Multimedia Class Scheduler Service, Microsoft Learn - finalidade do MMCSS, SystemResponsiveness, arredondamento e desativação em 100.
• AvSetMmThreadCharacteristicsW, Microsoft Learn - registro do thread atual em uma tarefa do MMCSS.
• AvSetMmThreadPriority, Microsoft Learn - prioridade relativa do thread registrado.
• AvRevertMmThreadCharacteristics, Microsoft Learn - conclusão do registro do thread.
• KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Fontes públicas e formulações verificadas: 2026-08-25.

A pesquisa e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, portanto o desenvolvedor tem interesse direto nos resultados. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas listadas. 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 é associado, autorizado, patrocinado ou aprovado pela Microsoft Corporation.

Histórico de alterações

• 2026-09-20: o disclaimer sobre conflito de interesses foi reforçado até a formulação completa com a titularidade da pesquisa e das ferramentas.
• 2026-08-25: primeira publicação; adicionadas duas séries separadas de p99, verificação da prioridade do thread, limites para áudio e jogos, além da restauração de estado confirmada.