SystemResponsiveness und MMCSS: Was die Werte 0, 10, 20 und 100 bewirken

Kurze Antwort

In BoosterX wird dieser Parameter durch die Einstellung „SystemResponsiveness“ dargestellt. Der Wert 10 ändert die MMCSS-Reserve, aber ein Vorteil gegenüber 20 wurde im geprüften Szenario nicht festgestellt; 100 deaktiviert MMCSS.

SystemResponsiveness ist kein Placebo. Es ist ein MMCSS-Parameter, den Windows normalisiert und beim Start anwendet. Im untersuchten Windows 11 ergab der Wert 0 denselben effektiven Zustand 20, und 10 änderte den MMCSS-Zustand, zeigte aber keinen Vorteil gegenüber 20 im synthetischen Scheduler-Test.

Der Wert 100 deaktivierte MMCSS. Die Thread-Registrierung wurde nicht durchgeführt, der Thread erhielt keine Prioritätsanhebung, und p99 der Latenz der synthetischen Scheduling-Workload stieg um etwa 11-12 ms gegenüber 20. Ein solches Ergebnis bedeutet nicht, dass Windows insgesamt um 60% langsamer geworden ist, und beweist keine Verschlechterung von FPS, Input-Latenz oder realem Audio.

Verwandte BoosterX-Einstellungen

Praktische Einstellungsseite: „CPU-Reserve für Hintergrundaufgaben“.

Zu prüfende Behauptung

Die Untersuchung prüfte drei separate Behauptungen:

1. Ob 0, 10, 20, 100 und der fehlende Wert den tatsächlichen MMCSS-Zustand nach dem Start ändern.
2. Ob 10 einen praktisch bedeutsamen Vorteil gegenüber 20 bei p99 der Latenz der synthetischen MMCSS-Workload unter voller CPU-Auslastung bietet.
3. Ob das Ergebnis bei deaktiviertem MMCSS durch den Verlust der Prioritätsanhebung des registrierten Threads erklärt wird.

Selbst eine bestätigte Änderung des Mechanismus und der synthetischen Metrik beweist keinen Einfluss auf die Nutzerlatenz, den Klang oder die Spielleistung.

Untersuchungsbereich

• Windows 11 Pro 25H2 x64, Build 26200.9168.
• VMware VM: 4 vCPU, 8 GB RAM, Energieschema Balanced.
• Hauptzustände: fehlender Wert, 0, 10, 20 und 100.
• Zusätzliche Grenzprüfung: 1, 9, 11, 19, 21, 99, 101 und 0xFFFFFFFF.
• Das Ergebnis bezieht sich auf eine virtuelle Maschine und einen Windows-Build.

Der Build wird durch die Update-Seite KB5121003 von Microsoft Support bestätigt.

Was Microsoft dokumentiert

Microsoft beschreibt MMCSS als Mechanismus, der es zeitkritischen Multimedia-Workloads ermöglicht, bevorzugten Zugriff auf die CPU zu erhalten, ohne Arbeit mit niedrigerer Priorität vollständig zu verdrängen. Der Parameter SystemResponsiveness wird in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile gespeichert.

In der MMCSS-Dokumentation wird angegeben:

• Werte, die nicht durch 10 teilbar sind, werden auf das nächstniedrigere Zehner abgerundet;
• Werte unter 10 und über 100 werden auf 20 gesetzt;
• der Wert 100 deaktiviert MMCSS;
• Games, Audio, Playback und andere Profile sind MMCSS-Aufgaben.

Die Anwendung verknüpft den aktuellen Thread über AvSetMmThreadCharacteristics mit einer Aufgabe, ändert die relative Priorität über AvSetMmThreadPriority und hebt die Registrierung über AvRevertMmThreadCharacteristics auf.

Die Dokumentation legt das Verhalten eines fehlenden Registry value nicht fest. Das Ergebnis unten ist eine Beobachtung nur für den geprüften Build.

Methodik

Die Hauptmetrik ist p99 der Latenz des Starts periodischer Arbeit im Profil Games bei voller Auslastung von vier vCPU. Ein unabhängiger Durchlauf entsprach einem Zustand nach einem separaten Windows-Start. Innerhalb jedes Durchlaufs wurden 2500 Perioden ausgeführt, sie wurden jedoch nicht als unabhängige Wiederholungen gezählt.

Für jeden Zustand wurden zwei Serien mit je 10 Starts durchgeführt. Die Reihenfolge der Zustände wurde balanciert, Ausreißer wurden nicht entfernt. Die praktisch bedeutsame Schwelle wurde im Voraus auf 1.784 ms festgelegt. Für die Differenz zum Zustand 20 wurde ein gepaartes Bootstrap-95%-CI verwendet.

Die Serien werden getrennt dargestellt: In der zweiten Serie lief eine zusätzliche validation-only ETW-Sitzung, die in der ersten nicht vorhanden war. Sie war nicht die Quelle der Hauptmetrik, aber der zweite Block erwies sich als verrauschter, weshalb die zusammengefasste Zahl aus 20 Durchläufen die Inhomogenität der Daten hätte verbergen können.

Die separate Mechanismusprüfung umfasste je vier Starts für 10, 20, 100 und den fehlenden Wert. Derselbe Thread wurde vor dem Versuch der MMCSS-Registrierung, danach und nach dem Cleanup gemessen. Geprüft wurden das Ergebnis der Registrierung, die Win32 thread priority und die tatsächliche Scheduler-Priorität per ETW. Alle 16 Hauptdurchläufe wurden akzeptiert; verlorene ETW events oder buffers gab es in dieser Serie nicht. Infrastruktur-Piloten wurden nicht in die Ergebnisse einbezogen.

Ergebnisse

Wie Windows die Werte verarbeitet hat

Eingetragen	Beobachteter Zustand nach dem Start	Ergebnis
fehlt	MMCSS gestoppt, Registrierung nicht durchgeführt, API gab 100 zurück	separate Beobachtung für diesen Build
0, 1, 9	API gab 20 zurück, MMCSS läuft	auf 20 normalisiert
10	API gab 10 zurück, MMCSS läuft	Wert wird verwendet
11, 19	API gab 10 zurück, MMCSS läuft	abgerundet
20	API gab 20 zurück, MMCSS läuft	Wert wird verwendet
21	API gab 20 zurück, MMCSS läuft	abgerundet
99	API gab 90 zurück, MMCSS läuft	abgerundet
100	MMCSS gestoppt, Registrierung nicht durchgeführt	dokumentierte Deaktivierung
101, 0xFFFFFFFF	API gab 20 zurück, MMCSS läuft	auf 20 normalisiert

Für numerische Werte stimmte die Zuordnung mit der Microsoft-Dokumentation überein. Beim fehlenden value wurde die Zahl 100 ohne gültige MMCSS-Registrierung zurückgegeben, daher ist sie als API fallback angegeben und nicht als Ergebnis einer Abfrage an einen laufenden MMCSS. Der deaktivierte Zustand wurde in diesem Build separat anhand des Dienstes und der Registrierung bestätigt, lässt sich aber nicht automatisch auf andere Windows-Versionen übertragen.

Eine zuverlässige Anwendung des neuen Zustands wurde nach einem Neustart beobachtet. Eine Änderung der Registry änderte nicht den Zustand eines bereits geöffneten MMCSS handle oder eines neuen Prozesses im aktuellen Start. Ein fehlgeschlagener Versuch, den Dienst zu stoppen und zu starten, gilt nicht als unterstützter Anwendungsweg.

p99 der synthetischen Latenz

Eine positive Differenz bedeutet eine höhere, also schlechtere, p99-Latenz gegenüber 20.

Vergleich mit 20	Serie 1, Differenz und 95% CI	Serie 2, Differenz und 95% CI	Schlussfolgerung
10	+0.625 ms [-1.111; +2.474]	+0.975 ms [-3.579; +5.613]	Vorteil nicht festgestellt; Äquivalenz nicht bewiesen
0	+1.267 ms [-0.014; +2.564]	-1.902 ms [-4.681; +0.718]	Ergebnis unbestimmt und in der Richtung unterschiedlich
100	+10.812 ms [+8.787; +12.915]	+12.074 ms [+9.669; +14.127]	praktisch bedeutsamer Schaden im synthetischen Proxy
fehlt	+11.640 ms [+9.690; +13.480]	+12.494 ms [+9.303; +16.208]	praktisch bedeutsamer Schaden im synthetischen Proxy

10 zeigte in keiner Serie einen praktisch bedeutsamen Vorteil gegenüber 20. Das breite Intervall der zweiten Serie lässt sowohl Nutzen als auch Schaden zu, daher kann das Ergebnis nicht als Beweis der Äquivalenz bezeichnet werden.

Was sich bei deaktiviertem MMCSS geändert hat

Zustand	Registrierung	MMCSS-Zustand	Win32 priority eines Threads	ETW priority eines Threads
20	4/4	läuft	0 -> 10 -> 0	8 -> 18 -> 8
10	4/4	läuft	0 -> 10 -> 0	8 -> 18 -> 8
100	0/4	gestoppt	0 -> 0 -> 0	8 -> 8 -> 8
fehlt	0/4	gestoppt	0 -> 0 -> 0	8 -> 8 -> 8

Die Abfolge in den beiden letzten Spalten bezeichnet den Zustand vor der Registrierung, nach dem Versuch der Registrierung und nach dem Cleanup. Die Process priority class änderte sich nicht.

Dies bestätigt direkt eine Ursache der Verschlechterung der synthetischen Metrik: Bei deaktiviertem MMCSS setzte der Test-Thread dieselbe Arbeit fort, erhielt aber keine Prioritätsanhebung. Der separate Beitrag von CPU quota und anderen Regeln der Ressourcenverrechnung wurde nicht isoliert.

100 und der fehlende Wert stimmten beim Dienstzustand, beim Registrierungsergebnis und bei der Thread-Priorität überein. Dies beweist nicht ihre vollständige Äquivalenz in allen internen und Nutzer-Szenarien.

Was bestätigt ist

• SystemResponsiveness ändert den beobachteten MMCSS-Zustand nach dem Windows-Start.
• 0 erzeugt keinen effektiven Zustand 0, sondern wird auf 20 normalisiert.
• 10 und 20 erlauben die Thread-Registrierung und ergeben in diesem Test denselben Übergang seiner Priorität.
• Ein praktisch bedeutsamer Vorteil von 10 gegenüber 20 bei der gewählten p99-Metrik wurde nicht festgestellt.
• 100 deaktiviert MMCSS; im geprüften Build wurde derselbe Zustand bei fehlendem value beobachtet.
• Bei deaktiviertem MMCSS erhielt der Test-Thread keine Prioritätsanhebung, und die synthetische p99-Latenz verschlechterte sich in beiden Serien.

Was nicht bestätigt ist

• Dass 10 und 20 für alle MMCSS-Workloads äquivalent sind.
• Dass 10 FPS erhöht, die Input-Latenz verringert oder den Klang verbessert.
• Dass 100 zwangsläufig audio glitches, Desynchronisation oder Probleme in einem konkreten Spiel verursacht.
• Dass die Beobachtung für den fehlenden value sich auf einem anderen Windows-Build wiederholt.
• Dass die erhaltenen Millisekunden eine physische End-to-End-Latenz sind.
• Dass das Ergebnis der virtuellen Maschine auf einen physischen PC übertragbar ist.

Einschränkungen

Die Untersuchung wurde auf einer VMware VM und einem Windows-Build durchgeführt. Das synthetische Profil Games erzeugt eine kontrollierte Konkurrenz um die CPU, bildet aber weder eine Spiel-Engine, einen Audiotreiber, eine reale Input-Pipeline noch ein Display-Scanout nach.

In der zweiten Serie wurde die zusätzliche ETW-Sitzung nur zur Validierung verwendet, konnte aber das allgemeine Rauschniveau verändern. Daher wurden die beiden Serien nicht zu einer Schätzung zusammengefasst. Die Mechanismusprüfung zeigt den Verlust der Prioritätsanhebung, trennt aber nicht den möglichen Beitrag von MMCSS quota und accounting policy ab.

Physischer Audiotest, FPS, Frametime, Click-to-Photon und Input-Latenz wurden nicht gemessen. Eine unabhängige Wiederholung auf einer anderen Maschine oder einem anderen Build gibt es bisher nicht.

Praktische Schlussfolgerung

Verwenden Sie 0 nicht als Weg, eine „Null-Reserve“ festzulegen: Windows setzt ihn auf 20. Betrachten Sie 10 nicht als bewiesen besten universellen Wert: In dieser VM wurde kein Vorteil gegenüber 20 festgestellt.

Verwenden Sie 100 nicht und löschen Sie den Wert nicht, um „Beschränkungen zu deaktivieren“. In der geprüften Umgebung deaktivierte dies MMCSS, nahm dem Thread die Prioritätsanhebung und verschlechterte die synthetische p99-Latenz merklich. Ohne einen separaten physischen Test lässt sich diese Schlussfolgerung nicht in eine genaue Prognose für FPS oder Klang umwandeln.

Für ein gewöhnliches System ist die sichere Schlussfolgerung auf die Beibehaltung des regulären Windows-Zustands beschränkt. Eine Änderung ist nur bei einer im Voraus gewählten Nutzermetrik, wiederholten gepaarten Messungen und bestätigter Rückkehr gerechtfertigt.

Wiederherstellung des Zustands

Eine kurze Nutzerempfehlung und der genaue Registry-Zustand sind auf der Seite „SystemResponsiveness“ veröffentlicht.

Nach jeder experimentellen Phase wurde die VM in den geschützten Ausgangszustand zurückversetzt. Ein Kontrollstart bestätigte den Registry value 20, einen laufenden MMCSS, das Fehlen einer aktiven Ablaufverfolgung und die Beendigung der Testprozesse. Nach der Prüfung wurde erneut zurückversetzt, die VM blieb ausgeschaltet.

Öffentliche Primärquellen

• Multimedia Class Scheduler Service, Microsoft Learn - Zweck von MMCSS, SystemResponsiveness, Rundung und Deaktivierung bei 100.
• AvSetMmThreadCharacteristicsW, Microsoft Learn - Registrierung des aktuellen Threads in einer MMCSS-Aufgabe.
• AvSetMmThreadPriority, Microsoft Learn - relative Priorität des registrierten Threads.
• AvRevertMmThreadCharacteristics, Microsoft Learn - Beendigung der Thread-Registrierung.
• KB5121003, Microsoft Support - Windows 11 Build 26200.9168.

Öffentliche Quellen und Formulierungen geprüft: 2026-08-25.

Die Untersuchung und die verwendeten Werkzeuge gehören dem Entwickler von BoosterX, daher hat der Entwickler ein direktes Interesse an den Ergebnissen. Methodik und Anwendungsgrenzen sind oben beschrieben, und die Schlussfolgerungen lassen sich anhand offener Daten und der aufgeführten öffentlichen Quellen überprüfen. Das Vorhandensein des Parameters im Produkt wurde nicht als Beweis verwendet; das unbestimmte Ergebnis für 10 und das negative Ergebnis der MMCSS-Deaktivierung wurden ohne Auswahl beibehalten.

BoosterX Wiki ist eine unabhängige Publikation und steht in keiner Verbindung zur Microsoft Corporation, ist von ihr nicht autorisiert, nicht gesponsert und nicht gebilligt.

Änderungsverlauf

• 2026-09-20: Der Disclaimer zum Interessenkonflikt wurde zu einer vollständigen Formulierung mit der Zugehörigkeit von Untersuchung und Werkzeugen erweitert.
• 2026-08-25: erste Veröffentlichung; zwei getrennte p99-Serien, die Prüfung der Thread-Priorität, die Grenzen für Audio und Spiele sowie die bestätigte Wiederherstellung des Zustands wurden hinzugefügt.