SystemResponsiveness och MMCSS: vad värdena 0, 10, 20 och 100 gör

Kort svar

I BoosterX representeras denna parameter av inställningen “SystemResponsiveness”. Värdet 10 ändrar MMCSS-reserven, men någon fördel gentemot 20 har inte fastställts i det testade scenariot; 100 inaktiverar MMCSS.

SystemResponsiveness är inte placebo. Det är en MMCSS-parameter som Windows normaliserar och tillämpar vid start. I den undersökta Windows 11 gav värdet 0 samma effektiva tillstånd 20, och 10 ändrade MMCSS-tillståndet men visade ingen fördel gentemot 20 i ett syntetiskt schemaläggartest.

Värdet 100 inaktiverade MMCSS. Trådregistrering utfördes inte, tråden fick ingen prioritetshöjning, och p99-fördröjningen för den syntetiska schemaläggningsworkloaden ökade med cirka 11-12 ms relativt 20. Ett sådant resultat betyder inte att Windows i allmänhet blev 60% långsammare, och det bevisar inte försämrad FPS, input latency eller verkligt ljud.

Relaterade inställningar i BoosterX

Praktisk inställningssida: «CPU-reserv för bakgrundsuppgifter».

Påståendet som granskas

Undersökningen granskade tre separata påståenden:

1. Huruvida 0, 10, 20, 100 och ett saknat värde ändrar MMCSS faktiska tillstånd efter start.
2. Huruvida 10 ger en praktiskt betydelsefull fördel gentemot 20 avseende p99-fördröjning för syntetisk MMCSS-workload vid full CPU-belastning.
3. Huruvida resultatet med MMCSS inaktiverat förklaras av att en registrerad tråd förlorar sin prioritetshöjning.

Även en bekräftad ändring av mekanismen och den syntetiska metriken bevisar inte påverkan på användarupplevd fördröjning, ljud eller spelprestanda.

Undersökningens omfattning

• Windows 11 Pro 25H2 x64, build 26200.9168.
• VMware VM: 4 vCPU, 8 GB RAM, energischemat Balanced.
• Huvudsakliga tillstånd: saknat värde, 0, 10, 20 och 100.
• Ytterligare gränskontroll: 1, 9, 11, 19, 21, 99, 101 och 0xFFFFFFFF.
• Resultatet gäller en virtuell maskin och en Windows-build.

Builden bekräftas av uppdateringssidan KB5121003 hos Microsoft Support.

Vad Microsoft dokumenterar

Microsoft beskriver MMCSS som en mekanism som låter time-sensitive multimedia-workload få prioriterad åtkomst till CPU utan att helt tränga undan arbete med lägre prioritet. Parametern SystemResponsiveness lagras i HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

I MMCSS-dokumentationen anges:

• värden som inte är jämna multiplar av 10 avrundas nedåt till närmaste tiotal;
• värden under 10 och över 100 justeras till 20;
• värdet 100 inaktiverar MMCSS;
• Games, Audio, Playback och andra profiler är MMCSS-uppgifter.

Programmet kopplar den aktuella tråden till en uppgift via AvSetMmThreadCharacteristics, ändrar den relativa prioriteten via AvSetMmThreadPriority och avregistrerar via AvRevertMmThreadCharacteristics.

Dokumentationen anger inte beteendet för ett saknat Registry value. Resultatet nedan är en observation endast för den testade builden.

Metod

Huvudmetriken är p99-fördröjning för start av periodiskt arbete i profilen Games vid full belastning av fyra vCPU. En oberoende körning motsvarade ett tillstånd efter en separat Windows-start. Inom varje körning utfördes 2500 perioder, men dessa räknades inte som oberoende upprepningar.

För varje tillstånd genomfördes två serier om 10 starter. Ordningen på tillstånden balanserades, extremvärden togs inte bort. Den praktiskt betydelsefulla tröskeln fastställdes i förväg till 1.784 ms. För skillnaden mot tillståndet 20 användes parat bootstrap 95% CI.

Serierna visas separat: i den andra serien kördes en extra validation-only ETW-session som inte fanns i den första. Den var inte källa till huvudmetriken, men det andra blocket visade sig vara brusigare, så det sammanslagna antalet om 20 körningar skulle kunna dölja inhomogenitet i data.

Den separata mekanismkontrollen omfattade fyra starter vardera för 10, 20, 100 och saknat värde. Samma tråd mättes före försök till MMCSS-registrering, efter den och efter cleanup. Resultatet av registreringen, Win32 thread priority och den faktiska schemaläggarprioriteten via ETW kontrollerades. Alla 16 huvudkörningar godtogs; inga förlorade ETW events eller buffers förekom i denna serie. Infrastrukturpiloter inkluderades inte i resultaten.

Resultat

Hur Windows behandlade värdena

Registrerat	Observerat tillstånd efter start	Resultat
saknas	MMCSS stoppad, registrering ej utförd, API returnerade 100	separat observation för denna build
0, 1, 9	API returnerade 20, MMCSS körs	normaliserat till 20
10	API returnerade 10, MMCSS körs	värdet används
11, 19	API returnerade 10, MMCSS körs	avrundat nedåt
20	API returnerade 20, MMCSS körs	värdet används
21	API returnerade 20, MMCSS körs	avrundat nedåt
99	API returnerade 90, MMCSS körs	avrundat nedåt
100	MMCSS stoppad, registrering ej utförd	dokumenterad inaktivering
101, 0xFFFFFFFF	API returnerade 20, MMCSS körs	normaliserat till 20

För numeriska värden stämde kartan med Microsofts dokumentation. Vid ett saknat value returnerades talet 100 utan giltig MMCSS-registrering, därför anges det som API fallback och inte som resultat av en förfrågan till en körande MMCSS. Det inaktiverade tillståndet i denna build bekräftades separat via tjänsten och registreringen, men det kan inte automatiskt överföras till andra Windows-versioner.

Tillförlitlig tillämpning av ett nytt tillstånd observerades efter omstart. En ändring i Registry ändrade inte tillståndet för ett redan öppet MMCSS handle eller en ny process i den aktuella starten. Ett misslyckat försök att stoppa och starta tjänsten räknas inte som ett supported sätt att tillämpa ändringen.

p99 för syntetisk fördröjning

En positiv skillnad innebär högre, det vill säga sämre, p99-fördröjning relativt 20.

Jämförelse med 20	Serie 1, skillnad och 95% CI	Serie 2, skillnad och 95% CI	Slutsats
10	+0.625 ms [-1.111; +2.474]	+0.975 ms [-3.579; +5.613]	fördel ej fastställd; ekvivalens ej bevisad
0	+1.267 ms [-0.014; +2.564]	-1.902 ms [-4.681; +0.718]	resultatet är obestämt och skiljer sig i riktning
100	+10.812 ms [+8.787; +12.915]	+12.074 ms [+9.669; +14.127]	praktiskt betydelsefull skada i syntetisk proxy
saknas	+11.640 ms [+9.690; +13.480]	+12.494 ms [+9.303; +16.208]	praktiskt betydelsefull skada i syntetisk proxy

10 visade ingen praktiskt betydelsefull fördel gentemot 20 i någon serie. Det breda intervallet i den andra serien tillåter både nytta och skada, därför kan resultatet inte kallas bevis för ekvivalens.

Vad som ändrades när MMCSS inaktiverades

Tillstånd	Registrering	MMCSS-tillstånd	Win32 priority för en tråd	ETW priority för en tråd
20	4/4	körs	0 -> 10 -> 0	8 -> 18 -> 8
10	4/4	körs	0 -> 10 -> 0	8 -> 18 -> 8
100	0/4	stoppad	0 -> 0 -> 0	8 -> 8 -> 8
saknas	0/4	stoppad	0 -> 0 -> 0	8 -> 8 -> 8

Sekvensen i de två sista kolumnerna betyder tillståndet före registrering, efter försök till registrering och efter cleanup. Process priority class ändrades inte.

Detta bekräftar direkt en orsak till försämringen av den syntetiska metriken: med MMCSS inaktiverat fortsatte testtråden samma arbete, men fick ingen prioritetshöjning. Det separata bidraget från CPU quota och andra regler för resursredovisning är inte isolerat.

100 och ett saknat värde överensstämde avseende tjänstens tillstånd, registreringsresultat och trådprioritet. Detta bevisar inte att de är fullständigt ekvivalenta i alla interna och användarrelaterade scenarier.

Vad som bekräftats

• SystemResponsiveness ändrar det observerade MMCSS-tillståndet efter Windows-start.
• 0 skapar inte ett effektivt tillstånd 0, utan normaliseras till 20.
• 10 och 20 tillåter trådregistrering och ger i detta test samma övergång av trådens prioritet.
• Någon praktiskt betydelsefull fördel för 10 gentemot 20 enligt den valda p99-metriken har inte fastställts.
• 100 inaktiverar MMCSS; i den testade builden observerades samma tillstånd vid ett saknat value.
• Vid inaktiverad MMCSS fick testtråden ingen prioritetshöjning, och den syntetiska p99-fördröjningen försämrades i båda serierna.

Vad som inte bekräftats

• Att 10 och 20 är ekvivalenta för alla MMCSS-workloads.
• Att 10 höjer FPS, minskar input latency eller förbättrar ljud.
• Att 100 nödvändigtvis orsakar audio glitches, osynkronisering eller problem i ett specifikt spel.
• Att observationen för ett saknat value upprepas på en annan Windows-build.
• Att de erhållna millisekunderna är fysisk end-to-end latency.
• Att resultatet från en virtuell maskin överförs till en fysisk PC.

Begränsningar

Undersökningen utfördes på en VMware VM och en Windows-build. Den syntetiska profilen Games skapar kontrollerad konkurrens om CPU, men återspeglar inte en spelmotor, en ljuddrivrutin, en verklig input pipeline eller display scanout.

I den andra serien användes en extra ETW-session endast för validering, men den kan ha ändrat den allmänna brusnivån. Därför har de två serierna inte slagits samman till en gemensam uppskattning. Mekanismkontrollen visar förlusten av prioritetshöjning, men isolerar inte det möjliga bidraget från MMCSS quota och accounting policy.

Fysiskt ljudtest, FPS, frametime, click-to-photon och input latency mättes inte. Någon oberoende upprepning på en annan maskin eller build finns ännu inte.

Praktisk slutsats

Använd inte 0 som ett sätt att ange “noll reserv”: Windows justerar det till 20. Betrakta inte 10 som ett bevisat bättre universellt värde: i denna VM har ingen fördel gentemot 20 fastställts.

Använd inte 100 och ta inte bort värdet för att “stänga av begränsningar”. I den testade miljön inaktiverade detta MMCSS, berövade tråden sin prioritetshöjning och försämrade den syntetiska p99-fördröjningen märkbart. Utan ett separat fysiskt test kan denna slutsats inte omvandlas till en exakt prognos för FPS eller ljud.

För ett vanligt system är den säkra slutsatsen begränsad till att bevara Windows standardtillstånd. En ändring är motiverad endast vid en i förväg vald användarmetrik, upprepade parade mätningar och en bekräftad återställning.

Återställning av tillstånd

En kortfattad användarrekommendation och det exakta registrytillståndet publiceras på sidan «SystemResponsiveness».

Efter varje experimentfas återställdes VM:en till ett skyddat utgångstillstånd. En kontrollstart bekräftade Registry value 20, en körande MMCSS, frånvaro av aktiv spårning och att testprocesserna avslutats. Efter kontrollen utfördes en ny återställning, och VM:en lämnades avstängd.

Offentliga primärkällor

• Multimedia Class Scheduler Service, Microsoft Learn - MMCSS syfte, SystemResponsiveness, avrundning och inaktivering vid 100.
• AvSetMmThreadCharacteristicsW, Microsoft Learn - registrering av den aktuella tråden i en MMCSS-uppgift.
• AvSetMmThreadPriority, Microsoft Learn - relativ prioritet för en registrerad tråd.
• AvRevertMmThreadCharacteristics, Microsoft Learn - avslutning av trådregistrering.
• KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Offentliga källor och formuleringar kontrollerades: 2026-08-25.

Undersökningen och de använda verktygen tillhör utvecklaren av BoosterX, därför har utvecklaren ett direkt intresse av resultaten. Metod och tillämpningsgränser beskrivs ovan, och slutsatserna kan verifieras mot öppna data och de angivna offentliga källorna. Parameterns förekomst i produkten användes inte som bevis; det obestämda resultatet för 10 och det negativa resultatet av att inaktivera MMCSS har bevarats utan gallring.

BoosterX Wiki är en oberoende publikation och är inte knuten till, auktoriserad av, sponsrad av eller godkänd av Microsoft Corporation.

Ändringshistorik

• 2026-09-20: intressekonflikt-disclaimern skärptes till en fullständig formulering med undersökningens och verktygens tillhörighet.
• 2026-08-25: första publiceringen; två separata p99-serier, kontroll av trådprioritet, gränser för ljud och spel samt bekräftad återställning av tillståndet lades till.