SystemResponsiveness y MMCSS: qué hacen los valores 0, 10, 20 y 100

En esta página

Respuesta corta

En BoosterX este parámetro se representa con la configuración «SystemResponsiveness». El valor 10 modifica la reserva de MMCSS, pero no se estableció una ventaja sobre 20 en el escenario probado; 100 desactiva MMCSS.

SystemResponsiveness no es un placebo. Es un parámetro de MMCSS que Windows normaliza y aplica durante el arranque. En el Windows 11 investigado, el valor 0 produjo el mismo estado efectivo 20, y 10 cambió el estado de MMCSS, pero no mostró ventaja sobre 20 en la prueba sintética del planificador.

El valor 100 desactivó MMCSS. No se realizó el registro del subproceso, el subproceso no recibió elevación de prioridad, y el p99 de latencia del workload sintético de planificación aumentó aproximadamente 11-12 ms respecto a 20. Tal resultado no significa que Windows en conjunto se volviera un 60% más lento, y no demuestra un empeoramiento de FPS, input latency o audio real.

Configuraciones relacionadas de BoosterX

Página práctica de configuración: «Reserva de CPU para tareas en segundo plano».

Afirmación verificable

La investigación verificó tres afirmaciones separadas:

Si 0, 10, 20, 100 y el valor ausente cambian el estado real de MMCSS tras el arranque.
Si 10 aporta una ventaja prácticamente significativa sobre 20 en el p99 de latencia del workload sintético de MMCSS con carga completa de CPU.
Si el resultado con MMCSS desactivado se explica por la pérdida de elevación de prioridad del subproceso registrado.

Incluso un cambio confirmado del mecanismo y de la métrica sintética no demuestra influencia sobre la latencia del usuario, el audio o el rendimiento en juegos.

Alcance de la investigación

Windows 11 Pro 25H2 x64, build 26200.9168.
VMware VM: 4 vCPU, 8 GB RAM, plan de energía Balanced.
Estados principales: valor ausente, 0, 10, 20 y 100.
Verificación adicional de límites: 1, 9, 11, 19, 21, 99, 101 y 0xFFFFFFFF.
El resultado se refiere a una sola máquina virtual y a una sola compilación de Windows.

La compilación se confirma con la página de actualización KB5121003 de Microsoft Support.

Qué documenta Microsoft

Microsoft describe MMCSS como un mecanismo que permite a un time-sensitive multimedia workload obtener acceso prioritario a la CPU sin desplazar por completo el trabajo de menor prioridad. El parámetro SystemResponsiveness se almacena en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

En la documentación de MMCSS se indica:

los valores que no son múltiplos de 10 se redondean hacia abajo al múltiplo de diez más cercano;
los valores inferiores a 10 y superiores a 100 se ajustan a 20;
el valor 100 desactiva MMCSS;
Games, Audio, Playback y otros perfiles son tareas de MMCSS.

La aplicación asocia el subproceso actual con una tarea mediante AvSetMmThreadCharacteristics, cambia la prioridad relativa mediante AvSetMmThreadPriority y anula el registro mediante AvRevertMmThreadCharacteristics.

La documentación no define el comportamiento de un Registry value ausente. Su resultado a continuación es una observación solo para la compilación probada.

Metodología

La métrica principal es el p99 de latencia de inicio del trabajo periódico en el perfil Games con carga completa de cuatro vCPU. Una ejecución independiente correspondía a un estado tras un arranque separado de Windows. Dentro de cada ejecución se realizaron 2500 periodos, pero no se consideraron repeticiones independientes.

Para cada estado se realizaron dos series de 10 arranques. El orden de los estados se balanceó, no se eliminaron valores atípicos. El umbral prácticamente significativo se estableció de antemano en 1.784 ms. Para la diferencia con el estado 20 se usó un bootstrap pareado con IC del 95%.

Las series se muestran por separado: en la segunda serie funcionaba una sesión ETW adicional solo de validación, que no existía en la primera. No fue la fuente de la métrica principal, pero el segundo bloque resultó más ruidoso, por lo que el número combinado de 20 ejecuciones podría haber ocultado la heterogeneidad de los datos.

La verificación separada del mecanismo incluyó cuatro arranques para 10, 20, 100 y el valor ausente. El mismo subproceso se midió antes del intento de registro en MMCSS, después de este y tras el cleanup. Se verificaron el resultado del registro, la Win32 thread priority y la prioridad real del planificador por ETW. Las 16 ejecuciones principales se aceptaron; no hubo pérdida de ETW events ni de buffers en esta serie. Los pilotos de infraestructura no se incluyeron en los resultados.

Resultados

Cómo procesó Windows los valores

Registrado	Estado observado tras el arranque	Resultado
ausente	MMCSS detenido, registro no realizado, la API devolvió 100	observación separada para esta compilación
`0`, `1`, `9`	la API devolvió 20, MMCSS funciona	normalizado a 20
`10`	la API devolvió 10, MMCSS funciona	valor utilizado
`11`, `19`	la API devolvió 10, MMCSS funciona	redondeado hacia abajo
`20`	la API devolvió 20, MMCSS funciona	valor utilizado
`21`	la API devolvió 20, MMCSS funciona	redondeado hacia abajo
`99`	la API devolvió 90, MMCSS funciona	redondeado hacia abajo
`100`	MMCSS detenido, registro no realizado	desactivación documentada
`101`, `0xFFFFFFFF`	la API devolvió 20, MMCSS funciona	normalizado a 20

Para los valores numéricos, el mapa coincidió con la documentación de Microsoft. Con el value ausente, el número 100 se devolvió sin un registro válido de MMCSS, por lo que se indica como API fallback, y no como resultado de una consulta a un MMCSS en funcionamiento. El estado desactivado en esta compilación se confirmó por separado según el servicio y el registro, pero no puede trasladarse automáticamente a otras versiones de Windows.

La aplicación fiable del nuevo estado se observó tras el reinicio. El cambio en el Registry no modificó el estado de un MMCSS handle ya abierto ni de un nuevo proceso en el arranque actual. Un intento fallido de detener e iniciar el servicio no se considera un método de aplicación soportado.

p99 de latencia sintética

Una diferencia positiva significa una latencia p99 más alta, es decir, peor, respecto a 20.

Comparación con `20`	Serie 1, diferencia e IC del 95%	Serie 2, diferencia e IC del 95%	Conclusión
`10`	`+0.625 ms` `[-1.111; +2.474]`	`+0.975 ms` `[-3.579; +5.613]`	ventaja no establecida; equivalencia no demostrada
`0`	`+1.267 ms` `[-0.014; +2.564]`	`-1.902 ms` `[-4.681; +0.718]`	resultado indeterminado y variable en dirección
`100`	`+10.812 ms` `[+8.787; +12.915]`	`+12.074 ms` `[+9.669; +14.127]`	daño prácticamente significativo en el proxy sintético
ausente	`+11.640 ms` `[+9.690; +13.480]`	`+12.494 ms` `[+9.303; +16.208]`	daño prácticamente significativo en el proxy sintético

10 no mostró una ventaja prácticamente significativa sobre 20 en ninguna serie. El amplio intervalo de la segunda serie admite tanto beneficio como daño, por lo que el resultado no puede llamarse prueba de equivalencia.

Qu cambió al desactivar MMCSS

Estado	Registro	Estado de MMCSS	Win32 priority de un subproceso	ETW priority de un subproceso
`20`	4/4	funciona	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`10`	4/4	funciona	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`100`	0/4	detenido	`0 -> 0 -> 0`	`8 -> 8 -> 8`
ausente	0/4	detenido	`0 -> 0 -> 0`	`8 -> 8 -> 8`

La secuencia en las dos últimas columnas significa el estado antes del registro, después del intento de registro y tras el cleanup. La Process priority class no cambió.

Esto confirma directamente una causa del empeoramiento de la métrica sintética: con MMCSS desactivado, el subproceso de prueba continuó el mismo trabajo, pero no recibió elevación de prioridad. La contribución separada de la CPU quota y de otras reglas de contabilidad de recursos no se aisló.

100 y el valor ausente coincidieron en el estado del servicio, el resultado del registro y la prioridad del subproceso. Esto no demuestra su equivalencia total en todos los escenarios internos y de usuario.

Qué se ha confirmado

SystemResponsiveness cambia el estado observado de MMCSS tras el arranque de Windows.
0 no crea un estado efectivo 0, sino que se normaliza a 20.
10 y 20 permiten el registro del subproceso y en esta prueba dan la misma transición de su prioridad.
No se estableció una ventaja prácticamente significativa de 10 sobre 20 según la métrica p99 elegida.
100 desactiva MMCSS; en la compilación probada se observó el mismo estado con el value ausente.
Con MMCSS desactivado, el subproceso de prueba no recibió elevación de prioridad, y la latencia p99 sintética empeoró en ambas series.

Qué no se ha confirmado

Que 10 y 20 sean equivalentes para todos los MMCSS workload.
Que 10 aumente los FPS, reduzca el input latency o mejore el audio.
Que 100 cause necesariamente audio glitches, desincronización o problemas en un juego concreto.
Que la observación para el value ausente se repita en otra compilación de Windows.
Que los milisegundos obtenidos sean una latencia física end-to-end.
Que el resultado de la máquina virtual se traslade a un PC físico.

Limitaciones

La investigación se realizó en una sola VMware VM y una sola compilación de Windows. El perfil sintético Games crea una competencia controlada por la CPU, pero no reproduce un motor de juego, un controlador de audio, un input pipeline real ni el display scanout.

En la segunda serie, la sesión ETW adicional se usó solo para validación, pero pudo cambiar el nivel general de ruido. Por eso las dos series no se combinaron en una sola estimación. La verificación del mecanismo muestra la pérdida de elevación de prioridad, pero no separa la posible contribución de la MMCSS quota y de la accounting policy.

No se midieron la prueba de audio física, los FPS, el frametime, el click-to-photon ni el input latency. Todavía no hay una repetición independiente en otra máquina o compilación.

Conclusión práctica

No use 0 como forma de establecer una «reserva cero»: Windows lo ajusta a 20. No considere 10 como un valor universal demostradamente mejor: en esta VM no se estableció una ventaja sobre 20.

No use 100 ni elimine el valor para «desactivar las limitaciones». En el entorno probado, esto desactivó MMCSS, privó al subproceso de la elevación de prioridad y empeoró notablemente la latencia p99 sintética. Sin una prueba física separada, esta conclusión no puede convertirse en una predicción exacta de FPS o audio.

Para un sistema normal, la conclusión segura se limita a conservar el estado predeterminado de Windows. El cambio solo se justifica con una métrica de usuario elegida de antemano, mediciones pareadas repetidas y una reversión confirmada.

Restauración del estado

La recomendación breve para el usuario y el estado exacto del registro están publicados en la página «SystemResponsiveness».

Tras cada fase experimental, la VM volvía a un estado inicial protegido. Un arranque de control confirmó el Registry value 20, MMCSS en funcionamiento, la ausencia de una traza activa y la finalización de los procesos de prueba. Tras la verificación se realizó una nueva reversión, y la VM se dejó apagada.

Fuentes primarias públicas

Multimedia Class Scheduler Service, Microsoft Learn - propósito de MMCSS, SystemResponsiveness, redondeo y desactivación con 100.
AvSetMmThreadCharacteristicsW, Microsoft Learn - registro del subproceso actual en una tarea de MMCSS.
AvSetMmThreadPriority, Microsoft Learn - prioridad relativa del subproceso registrado.
AvRevertMmThreadCharacteristics, Microsoft Learn - finalización del registro del subproceso.
KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Las fuentes públicas y las formulaciones se verificaron: 2026-08-25.

La investigación y las herramientas utilizadas pertenecen al desarrollador de BoosterX, por lo que el desarrollador tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones pueden verificarse con los datos abiertos y las fuentes públicas enumeradas. La presencia del parámetro en el producto no se usó como prueba; el resultado indeterminado para 10 y el resultado negativo de desactivar MMCSS se conservaron sin selección.

BoosterX Wiki es una publicación independiente y no está asociada, autorizada, patrocinada ni aprobada por Microsoft Corporation.

Historial de cambios

2026-09-20: el descargo de responsabilidad sobre el conflicto de intereses se reforzó hasta la formulación completa con la pertenencia de la investigación y las herramientas.
2026-08-25: primera publicación; se añadieron dos series separadas de p99, la verificación de la prioridad del subproceso, los límites para audio y juegos, así como la restauración confirmada del estado.