SystemResponsiveness et MMCSS : ce que font les valeurs 0, 10, 20 et 100

Sur cette page

Réponse courte

Dans BoosterX, ce paramètre est représenté par le réglage « SystemResponsiveness ». La valeur 10 modifie la réservation MMCSS, mais aucun avantage sur 20 n’a été établi dans le scénario testé ; 100 désactive MMCSS.

SystemResponsiveness n’est pas un placebo. C’est un paramètre MMCSS que Windows normalise et applique au chargement. Dans le Windows 11 étudié, la valeur 0 a produit le même état effectif 20, et 10 a modifié l’état MMCSS, mais n’a montré aucun avantage sur 20 dans un test synthétique du planificateur.

La valeur 100 a désactivé MMCSS. L’enregistrement du thread n’était pas effectué, le thread ne recevait pas de rehaussement de priorité, et le p99 de latence du workload synthétique de planification a augmenté d’environ 11-12 ms par rapport à 20. Ce résultat ne signifie pas que Windows est globalement devenu 60% plus lent, et ne prouve pas de dégradation des FPS, de l’input latency ou de l’audio réel.

Réglages BoosterX associés

Page pratique de configuration : « Réserve CPU pour les tâches en arrière-plan ».

Affirmation vérifiable

L’étude vérifiait trois affirmations distinctes :

Si 0, 10, 20, 100 et la valeur absente modifient l’état réel de MMCSS après le chargement.
Si 10 apporte un avantage pratiquement significatif sur 20 en p99 de latence du workload MMCSS synthétique sous pleine charge CPU.
Si le résultat avec MMCSS désactivé s’explique par la perte du rehaussement de priorité du thread enregistré.

Même un changement confirmé du mécanisme et de la métrique synthétique ne prouve pas d’effet sur la latence utilisateur, l’audio ou les performances en jeu.

Périmètre de l’étude

Windows 11 Pro 25H2 x64, build 26200.9168.
VMware VM : 4 vCPU, 8 GB RAM, plan d’alimentation Balanced.
États principaux : valeur absente, 0, 10, 20 et 100.
Vérification supplémentaire des bornes : 1, 9, 11, 19, 21, 99, 101 et 0xFFFFFFFF.
Le résultat concerne une seule machine virtuelle et une seule build Windows.

La build est confirmée par la page de mise à jour KB5121003 de Microsoft Support.

Ce que documente Microsoft

Microsoft décrit MMCSS comme un mécanisme qui permet à un workload multimédia time-sensitive d’obtenir un accès prioritaire au CPU sans évincer complètement le travail de priorité inférieure. Le paramètre SystemResponsiveness est stocké dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

Dans la documentation MMCSS, il est indiqué :

les valeurs non multiples de 10 sont arrondies vers le bas au dizainier le plus proche ;
les valeurs inférieures à 10 et supérieures à 100 sont ramenées à 20 ;
la valeur 100 désactive MMCSS ;
Games, Audio, Playback et d’autres profils sont des tâches MMCSS.

L’application associe le thread courant à une tâche via AvSetMmThreadCharacteristics, modifie la priorité relative via AvSetMmThreadPriority et annule l’enregistrement via AvRevertMmThreadCharacteristics.

La documentation ne définit pas le comportement d’une Registry value absente. Son résultat ci-dessous est une observation valable uniquement pour la build testée.

Méthodologie

La métrique principale est le p99 de latence de lancement d’un travail périodique dans le profil Games sous pleine charge des quatre vCPU. Un passage indépendant correspondait à un état après un chargement distinct de Windows. À l’intérieur de chaque passage, 2500 périodes étaient exécutées, mais elles n’étaient pas considérées comme des répétitions indépendantes.

Pour chaque état, deux séries de 10 chargements ont été réalisées. L’ordre des états était équilibré, les valeurs aberrantes n’ont pas été supprimées. Le seuil pratiquement significatif a été fixé à l’avance au niveau 1.784 ms. Pour la différence avec l’état 20, un bootstrap apparié à 95% CI a été utilisé.

Les séries sont présentées séparément : dans la deuxième série, une session ETW supplémentaire validation-only était active, absente de la première. Elle n’était pas la source de la métrique principale, mais le deuxième bloc s’est révélé plus bruité, c’est pourquoi le nombre combiné de 20 passages aurait pu masquer une hétérogénéité des données.

Une vérification distincte du mécanisme comprenait quatre chargements pour 10, 20, 100 et la valeur absente. Le même thread était mesuré avant la tentative d’enregistrement MMCSS, après celle-ci et après le cleanup. Le résultat de l’enregistrement, la Win32 thread priority et la priorité réelle du planificateur via ETW étaient vérifiés. Les 16 passages principaux ont tous été acceptés ; aucun ETW event ou buffer perdu n’a été constaté dans cette série. Les pilotes d’infrastructure n’ont pas été inclus dans les résultats.

Résultats

Comment Windows a traité les valeurs

Écrit	État observé après le chargement	Résultat
absent	MMCSS arrêté, enregistrement non effectué, API a renvoyé 100	observation distincte pour cette build
`0`, `1`, `9`	API a renvoyé 20, MMCSS fonctionne	normalisé à 20
`10`	API a renvoyé 10, MMCSS fonctionne	valeur utilisée
`11`, `19`	API a renvoyé 10, MMCSS fonctionne	arrondi vers le bas
`20`	API a renvoyé 20, MMCSS fonctionne	valeur utilisée
`21`	API a renvoyé 20, MMCSS fonctionne	arrondi vers le bas
`99`	API a renvoyé 90, MMCSS fonctionne	arrondi vers le bas
`100`	MMCSS arrêté, enregistrement non effectué	désactivation documentée
`101`, `0xFFFFFFFF`	API a renvoyé 20, MMCSS fonctionne	normalisé à 20

Pour les valeurs numériques, la carte correspondait à la documentation Microsoft. Avec une value absente, le nombre 100 a été renvoyé sans enregistrement MMCSS valide, c’est pourquoi il est indiqué comme API fallback, et non comme résultat d’une requête à un MMCSS en fonctionnement. L’état désactivé dans cette build était confirmé séparément par le service et l’enregistrement, mais il ne peut pas être transposé automatiquement à d’autres versions de Windows.

L’application fiable du nouvel état a été observée après redémarrage. La modification du Registry n’a pas changé l’état d’un MMCSS handle déjà ouvert ni d’un nouveau processus dans le chargement en cours. Une tentative infructueuse d’arrêt et de démarrage du service n’est pas considérée comme un moyen d’application pris en charge.

p99 de latence synthétique

Une différence positive signifie une p99 de latence plus élevée, donc pire, par rapport à 20.

Comparaison avec `20`	Série 1, différence et 95% CI	Série 2, différence et 95% CI	Conclusion
`10`	`+0.625 ms` `[-1.111; +2.474]`	`+0.975 ms` `[-3.579; +5.613]`	avantage non établi ; équivalence non prouvée
`0`	`+1.267 ms` `[-0.014; +2.564]`	`-1.902 ms` `[-4.681; +0.718]`	résultat indéterminé et variable en direction
`100`	`+10.812 ms` `[+8.787; +12.915]`	`+12.074 ms` `[+9.669; +14.127]`	préjudice pratiquement significatif dans le proxy synthétique
absent	`+11.640 ms` `[+9.690; +13.480]`	`+12.494 ms` `[+9.303; +16.208]`	préjudice pratiquement significatif dans le proxy synthétique

10 n’a montré aucun avantage pratiquement significatif sur 20 dans aucune série. L’intervalle large de la deuxième série admet aussi bien un bénéfice qu’un préjudice, c’est pourquoi le résultat ne peut pas être qualifié de preuve d’équivalence.

Ce qui a changé lors de la désactivation de MMCSS

État	Enregistrement	État MMCSS	Win32 priority d’un thread	ETW priority d’un thread
`20`	4/4	fonctionne	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`10`	4/4	fonctionne	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`100`	0/4	arrêté	`0 -> 0 -> 0`	`8 -> 8 -> 8`
absent	0/4	arrêté	`0 -> 0 -> 0`	`8 -> 8 -> 8`

La séquence dans les deux dernières colonnes signifie l’état avant l’enregistrement, après la tentative d’enregistrement et après le cleanup. La Process priority class n’a pas changé.

Cela confirme directement une cause de la dégradation de la métrique synthétique : avec MMCSS désactivé, le thread de test poursuivait le même travail, mais ne recevait pas de rehaussement de priorité. La contribution distincte du CPU quota et d’autres règles de comptabilisation des ressources n’est pas isolée.

100 et la valeur absente coïncidaient par l’état du service, le résultat de l’enregistrement et la priorité du thread. Cela ne prouve pas leur équivalence totale dans tous les scénarios internes et utilisateur.

Ce qui est confirmé

SystemResponsiveness modifie l’état observé de MMCSS après le chargement de Windows.
0 ne crée pas d’état effectif 0, mais est normalisé à 20.
10 et 20 permettent l’enregistrement du thread et donnent dans ce test la même transition de sa priorité.
Aucun avantage pratiquement significatif de 10 sur 20 selon la métrique p99 choisie n’a été établi.
100 désactive MMCSS ; dans la build testée, le même état a été observé avec une value absente.
Avec MMCSS désactivé, le thread de test n’a pas reçu de rehaussement de priorité, et la p99 de latence synthétique s’est dégradée dans les deux séries.

Ce qui n’est pas confirmé

Que 10 et 20 sont équivalents pour tous les workload MMCSS.
Que 10 augmente les FPS, réduit l’input latency ou améliore l’audio.
Que 100 provoque nécessairement des audio glitches, une désynchronisation ou des problèmes dans un jeu précis.
Que l’observation pour la value absente se reproduit sur une autre build Windows.
Que les millisecondes obtenues sont une latence physique end-to-end.
Que le résultat de la machine virtuelle se transpose à un PC physique.

Limites

L’étude a été réalisée sur une seule VMware VM et une seule build Windows. Le profil synthétique Games crée une concurrence contrôlée pour le CPU, mais ne reproduit pas un moteur de jeu, un pilote audio, un input pipeline réel ou un display scanout.

Dans la deuxième série, la session ETW supplémentaire servait uniquement à la validation, mais pouvait modifier le niveau de bruit global. C’est pourquoi les deux séries ne sont pas combinées en une seule estimation. La vérification du mécanisme montre la perte du rehaussement de priorité, mais ne sépare pas la contribution possible du MMCSS quota et de l’accounting policy.

Aucun test audio physique, FPS, frametime, click-to-photon ou input latency n’a été mesuré. Il n’existe pas encore de reproduction indépendante sur une autre machine ou build.

Conclusion pratique

N’utilisez pas 0 comme moyen de définir une « réserve nulle » : Windows le ramène à 20. Ne considérez pas 10 comme une valeur universelle démontrée meilleure : dans cette VM, aucun avantage sur 20 n’a été établi.

N’utilisez pas 100 et ne supprimez pas la valeur pour « désactiver les limitations ». Dans l’environnement testé, cela a désactivé MMCSS, privé le thread du rehaussement de priorité et nettement dégradé la p99 de latence synthétique. Sans test physique distinct, cette conclusion ne peut pas être transformée en prédiction précise des FPS ou de l’audio.

Pour un système ordinaire, la conclusion sûre se limite au maintien de l’état Windows par défaut. Une modification n’est justifiée qu’avec une métrique utilisateur choisie à l’avance, des mesures appariées répétées et un retour confirmé.

Restauration de l’état

La recommandation utilisateur succincte et l’état exact du registre sont publiés sur la page « SystemResponsiveness ».

Après chaque phase expérimentale, la VM revenait à un état initial protégé. Un chargement de contrôle a confirmé la Registry value 20, un MMCSS en fonctionnement, l’absence de trace active et la fin des processus de test. Après vérification, un retour supplémentaire a été effectué, la VM a été laissée éteinte.

Sources primaires publiques

Multimedia Class Scheduler Service, Microsoft Learn - rôle de MMCSS, SystemResponsiveness, arrondi et désactivation à 100.
AvSetMmThreadCharacteristicsW, Microsoft Learn - enregistrement du thread courant dans une tâche MMCSS.
AvSetMmThreadPriority, Microsoft Learn - priorité relative du thread enregistré.
AvRevertMmThreadCharacteristics, Microsoft Learn - fin de l’enregistrement du thread.
KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Les sources publiques et les formulations ont été vérifiées : 2026-08-25.

L’étude et les outils utilisés appartiennent au développeur de BoosterX, le développeur a donc un intérêt direct dans les résultats. La méthodologie et les limites d’applicabilité sont décrites ci-dessus, et les conclusions peuvent être vérifiées à partir des données ouvertes et des sources publiques énumérées. La présence du paramètre dans le produit n’a pas été utilisée comme preuve ; le résultat indéterminé pour 10 et le résultat négatif de la désactivation de MMCSS sont conservés sans sélection.

BoosterX Wiki est une publication indépendante et n’est ni liée, ni autorisée, ni sponsorisée, ni approuvée par Microsoft Corporation.

Historique des modifications

2026-09-20: le disclaimer sur le conflit d’intérêts est renforcé jusqu’à une formulation complète avec l’appartenance de l’étude et des outils.
2026-08-25: première publication ; ajout de deux séries distinctes de p99, de la vérification de la priorité du thread, des limites pour l’audio et les jeux, ainsi que de la restauration confirmée de l’état.