Gå til indhold

SystemResponsiveness og MMCSS: hvad værdierne 0, 10, 20 og 100 gør

På denne side

I BoosterX er denne parameter repræsenteret ved indstillingen “SystemResponsiveness”. Værdien 10 ændrer MMCSS-reserven, men en fordel frem for 20 er ikke fastslået i det testede scenarie; 100 deaktiverer MMCSS.

SystemResponsiveness er ikke placebo. Det er en MMCSS-parameter, som Windows normaliserer og anvender ved indlæsning. I den undersøgte Windows 11 gav værdien 0 samme effektive tilstand 20, og 10 ændrede MMCSS-tilstanden, men viste ingen fordel frem for 20 i den syntetiske schedulertest.

Værdien 100 deaktiverede MMCSS. Trådregistrering blev ikke udført, tråden fik ingen prioritetsforhøjelse, og p99-forsinkelsen for den syntetiske scheduling-workload steg med cirka 11-12 ms i forhold til 20. Et sådant resultat betyder ikke, at Windows som helhed blev 60% langsommere, og det beviser ikke en forringelse af FPS, input latency eller reel lyd.

Praktisk indstillingsside: «CPU-reserve til baggrundsopgaver».

Undersøgelsen efterprøvede tre separate udsagn:

  1. Om 0, 10, 20, 100 og den manglende værdi ændrer MMCSS’ faktiske tilstand efter indlæsning.
  2. Om 10 giver en praktisk betydningsfuld fordel frem for 20 målt på p99-forsinkelse for syntetisk MMCSS-workload ved fuld CPU-belastning.
  3. Om resultatet ved deaktiveret MMCSS forklares ved tabet af prioritetsforhøjelse for den registrerede tråd.

Selv en bekræftet ændring af mekanismen og den syntetiske metrik beviser ikke en påvirkning af brugeroplevet forsinkelse, lyd eller spilydelse.

  • Windows 11 Pro 25H2 x64, build 26200.9168.
  • VMware VM: 4 vCPU, 8 GB RAM, strømplanen Balanced.
  • Hovedtilstande: manglende værdi, 0, 10, 20 og 100.
  • Yderligere grænsekontrol: 1, 9, 11, 19, 21, 99, 101 og 0xFFFFFFFF.
  • Resultatet gælder for én virtuel maskine og én Windows-build.

Builden bekræftes af opdateringssiden KB5121003 fra Microsoft Support.

Microsoft beskriver MMCSS som en mekanisme, der gør det muligt for time-sensitive multimedia workload at få prioriteret adgang til CPU’en uden fuldt ud at fortrænge arbejde med lavere prioritet. Parameteren SystemResponsiveness gemmes i HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

I MMCSS-dokumentationen står der:

  • værdier, der ikke er delelige med 10, rundes ned til nærmeste tier;
  • værdier under 10 og over 100 sættes til 20;
  • værdien 100 deaktiverer MMCSS;
  • Games, Audio, Playback og andre profiler er MMCSS-opgaver.

Programmet knytter den aktuelle tråd til en opgave via AvSetMmThreadCharacteristics, ændrer den relative prioritet via AvSetMmThreadPriority og ophæver registreringen via AvRevertMmThreadCharacteristics.

Dokumentationen fastlægger ikke adfærden for en manglende Registry value. Resultatet nedenfor er en observation, der kun gælder for den testede build.

Hovedmetrikken er p99-forsinkelsen for start af periodisk arbejde i profilen Games ved fuld belastning af fire vCPU’er. Et enkelt uafhængigt gennemløb svarede til én tilstand efter en separat Windows-indlæsning. Inden for hvert gennemløb blev der udført 2500 perioder, men de blev ikke betragtet som uafhængige gentagelser.

For hver tilstand blev der gennemført to serier med 10 indlæsninger hver. Rækkefølgen af tilstande blev balanceret, og outliers blev ikke fjernet. Den praktisk betydningsfulde tærskel blev på forhånd fastsat til 1.784 ms. Til forskellen fra tilstanden 20 blev der anvendt parret bootstrap 95% CI.

Serierne vises separat: i den anden serie kørte en ekstra validation-only ETW-session, som ikke var til stede i den første. Den var ikke kilde til hovedmetrikken, men den anden blok viste sig mere støjende, så det samlede antal på 20 gennemløb kunne have skjult uensartethed i dataene.

Den separate mekanismekontrol omfattede fire indlæsninger for 10, 20, 100 og den manglende værdi. Den samme tråd blev målt før forsøget på MMCSS-registrering, efter den og efter cleanup. Resultatet af registreringen, Win32 thread priority og den faktiske schedulerprioritet via ETW blev kontrolleret. Alle 16 hovedgennemløb blev accepteret; der var ingen tabte ETW events eller buffers i denne serie. Infrastrukturpiloter blev ikke medtaget i resultaterne.

Skrevet Observeret tilstand efter indlæsning Resultat
mangler MMCSS stoppet, registrering ikke udført, API returnerede 100 separat observation for denne build
0, 1, 9 API returnerede 20, MMCSS kører normaliseret til 20
10 API returnerede 10, MMCSS kører værdien bruges
11, 19 API returnerede 10, MMCSS kører rundet ned
20 API returnerede 20, MMCSS kører værdien bruges
21 API returnerede 20, MMCSS kører rundet ned
99 API returnerede 90, MMCSS kører rundet ned
100 MMCSS stoppet, registrering ikke udført dokumenteret deaktivering
101, 0xFFFFFFFF API returnerede 20, MMCSS kører normaliseret til 20

For de numeriske værdier stemte kortet overens med Microsofts dokumentation. Ved den manglende value returneredes tallet 100 uden gyldig MMCSS-registrering, derfor er det angivet som API fallback og ikke som resultatet af en forespørgsel til et kørende MMCSS. Den deaktiverede tilstand i denne build blev bekræftet separat via tjenesten og registreringen, men den kan ikke automatisk overføres til andre Windows-versioner.

Pålidelig anvendelse af den nye tilstand blev observeret efter genstart. Ændring af Registry ændrede ikke tilstanden for et allerede åbent MMCSS handle eller en ny proces i den aktuelle indlæsning. Et mislykket forsøg på at stoppe og starte tjenesten betragtes ikke som en understøttet måde at anvende det på.

En positiv forskel betyder en højere, altså dårligere, p99-forsinkelse i forhold til 20.

Sammenligning med 20 Serie 1, forskel og 95% CI Serie 2, forskel og 95% CI Konklusion
10 +0.625 ms [-1.111; +2.474] +0.975 ms [-3.579; +5.613] fordel ikke fastslået; ækvivalens ikke bevist
0 +1.267 ms [-0.014; +2.564] -1.902 ms [-4.681; +0.718] resultatet er ubestemt og varierer i retning
100 +10.812 ms [+8.787; +12.915] +12.074 ms [+9.669; +14.127] praktisk betydningsfuld skade i syntetisk proxy
mangler +11.640 ms [+9.690; +13.480] +12.494 ms [+9.303; +16.208] praktisk betydningsfuld skade i syntetisk proxy

10 viste ingen praktisk betydningsfuld fordel frem for 20 i nogen af serierne. Det brede interval i den anden serie tillader både gavn og skade, derfor kan resultatet ikke kaldes et bevis på ækvivalens.

Hvad ændrede sig ved deaktivering af MMCSS

Sektion kaldt “Hvad ændrede sig ved deaktivering af MMCSS”
Tilstand Registrering MMCSS-tilstand Win32 priority for én tråd ETW priority for én tråd
20 4/4 kører 0 -> 10 -> 0 8 -> 18 -> 8
10 4/4 kører 0 -> 10 -> 0 8 -> 18 -> 8
100 0/4 stoppet 0 -> 0 -> 0 8 -> 8 -> 8
mangler 0/4 stoppet 0 -> 0 -> 0 8 -> 8 -> 8

Sekvensen i de to sidste kolonner betyder tilstanden før registrering, efter forsøget på registrering og efter cleanup. Process priority class blev ikke ændret.

Dette bekræfter direkte én årsag til forringelsen af den syntetiske metrik: ved deaktiveret MMCSS fortsatte testtråden det samme arbejde, men fik ingen prioritetsforhøjelse. Det separate bidrag fra CPU quota og andre regler for ressourceafregning er ikke isoleret.

100 og den manglende værdi stemte overens med hensyn til tjenestetilstand, registreringsresultat og trådprioritet. Det beviser ikke deres fuldstændige ækvivalens i alle interne og brugerrelaterede scenarier.

  • SystemResponsiveness ændrer den observerede MMCSS-tilstand efter Windows-indlæsning.
  • 0 skaber ikke en effektiv tilstand 0, men normaliseres til 20.
  • 10 og 20 tillader trådregistrering og giver i denne test samme overgang i dens prioritet.
  • En praktisk betydningsfuld fordel for 10 frem for 20 målt på den valgte p99-metrik er ikke fastslået.
  • 100 deaktiverer MMCSS; i den testede build blev samme tilstand observeret ved en manglende value.
  • Ved deaktiveret MMCSS fik testtråden ingen prioritetsforhøjelse, og den syntetiske p99-forsinkelse blev forringet i begge serier.
  • At 10 og 20 er ækvivalente for alle MMCSS-workloads.
  • At 10 øger FPS, reducerer input latency eller forbedrer lyd.
  • At 100 nødvendigvis forårsager audio glitches, desynkronisering eller problemer i et bestemt spil.
  • At observationen for den manglende value gentages på en anden Windows-build.
  • At de målte millisekunder er fysisk end-to-end latency.
  • At resultatet fra den virtuelle maskine overføres til en fysisk PC.

Undersøgelsen blev udført på én VMware VM og én Windows-build. Den syntetiske profil Games skaber kontrolleret konkurrence om CPU’en, men genskaber ikke en spilmotor, en lyddriver, et reelt input pipeline eller display scanout.

I den anden serie blev den ekstra ETW-session kun brugt til validering, men den kan have ændret det generelle støjniveau. Derfor er de to serier ikke slået sammen til én vurdering. Mekanismekontrollen viser tabet af prioritetsforhøjelse, men adskiller ikke det mulige bidrag fra MMCSS quota og accounting policy.

Fysisk lydtest, FPS, frametime, click-to-photon og input latency blev ikke målt. Der findes endnu ingen uafhængig gentagelse på en anden maskine eller build.

Brug ikke 0 som en måde at sætte “nul reserve”: Windows sætter den til 20. Betragt ikke 10 som en bevist bedre universel værdi: i denne VM er der ikke fastslået en fordel frem for 20.

Brug ikke 100, og slet ikke værdien for at “deaktivere begrænsninger”. I det testede miljø deaktiverede dette MMCSS, fratog tråden prioritetsforhøjelsen og forringede den syntetiske p99-forsinkelse mærkbart. Uden en separat fysisk test kan denne konklusion ikke omdannes til en præcis prognose for FPS eller lyd.

For et almindeligt system er den sikre konklusion begrænset til at bevare Windows’ standardtilstand. En ændring er kun berettiget ved en på forhånd valgt brugermetrik, gentagne parrede målinger og en bekræftet tilbagevenden.

Den korte brugeranbefaling og den præcise registertilstand er offentliggjort på siden «SystemResponsiveness».

Efter hver eksperimentel fase blev VM’en ført tilbage til den beskyttede udgangstilstand. En kontrolindlæsning bekræftede Registry value 20, et kørende MMCSS, fravær af aktiv tracing og afslutning af testprocesserne. Efter kontrollen blev tilbageførslen gentaget, og VM’en blev efterladt slukket.

Offentlige kilder og formuleringer er kontrolleret: 2026-08-25.

Undersøgelsen og de anvendte værktøjer tilhører BoosterX’ udvikler, derfor har udvikleren en direkte interesse i resultaterne. Metoden og anvendelsesgrænserne er beskrevet ovenfor, og konklusionerne kan efterprøves via åbne data og de anførte offentlige kilder. Tilstedeværelsen af parameteren i produktet blev ikke brugt som bevis; det ubestemte resultat for 10 og det negative resultat af MMCSS-deaktivering er bevaret uden udvælgelse.

BoosterX Wiki er en uafhængig publikation og er ikke forbundet med, autoriseret af, sponsoreret af eller godkendt af Microsoft Corporation.

  • 2026-09-20: interessekonflikt-disclaimer styrket til en fuld formulering med angivelse af ejerskabet til undersøgelsen og værktøjerne.
  • 2026-08-25: første publikation; tilføjet to separate p99-serier, kontrol af trådprioritet, grænser for lyd og spil samt bekræftet gendannelse af tilstand.