SystemResponsiveness e MMCSS: cosa fanno i valori 0, 10, 20 e 100

In questa pagina

Risposta breve

In BoosterX questo parametro è rappresentato dall’impostazione «SystemResponsiveness». Il valore 10 modifica la riserva MMCSS, ma in uno scenario verificato non è stato stabilito alcun vantaggio rispetto a 20; 100 disattiva MMCSS.

SystemResponsiveness non è un placebo. È un parametro MMCSS che Windows normalizza e applica al caricamento. Nel Windows 11 esaminato il valore 0 ha prodotto lo stesso stato effettivo 20, mentre 10 ha modificato lo stato MMCSS ma non ha mostrato alcun vantaggio rispetto a 20 in un test sintetico dello scheduler.

Il valore 100 ha disattivato MMCSS. La registrazione del thread non è stata eseguita, il thread non ha ricevuto l’aumento di priorità e il p99 della latenza del workload sintetico dello scheduler è cresciuto di circa 11-12 ms rispetto a 20. Questo risultato non significa che Windows nel complesso sia diventato più lento del 60%, né dimostra un peggioramento di FPS, input latency o audio reale.

Impostazioni BoosterX correlate

Pagina pratica di configurazione: «Riserva CPU per attività in background».

Affermazione verificabile

Lo studio verificava tre affermazioni distinte:

Se 0, 10, 20, 100 e il valore assente modifichino lo stato effettivo di MMCSS dopo il caricamento.
Se 10 offra un vantaggio praticamente significativo rispetto a 20 sul p99 della latenza del workload MMCSS sintetico a CPU completamente carica.
Se il risultato con MMCSS disattivato sia spiegato dalla perdita dell’aumento di priorità del thread registrato.

Anche una modifica confermata del meccanismo e della metrica sintetica non dimostra un impatto sulla latenza percepita dall’utente, sull’audio o sulle prestazioni di gioco.

Ambito dello studio

Windows 11 Pro 25H2 x64, build 26200.9168.
VMware VM: 4 vCPU, 8 GB RAM, piano di alimentazione Balanced.
Stati principali: valore assente, 0, 10, 20 e 100.
Verifica aggiuntiva dei limiti: 1, 9, 11, 19, 21, 99, 101 e 0xFFFFFFFF.
Il risultato si riferisce a una singola macchina virtuale e a una singola build di Windows.

La build è confermata dalla pagina di aggiornamento KB5121003 di Microsoft Support.

Cosa documenta Microsoft

Microsoft descrive MMCSS come un meccanismo che consente a un workload multimediale time-sensitive di ottenere accesso prioritario alla CPU senza escludere completamente il lavoro a priorità inferiore. Il parametro SystemResponsiveness è memorizzato in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

Nella documentazione MMCSS è indicato:

i valori non multipli di 10 vengono arrotondati per difetto alla decina più vicina;
i valori inferiori a 10 e superiori a 100 vengono portati a 20;
il valore 100 disattiva MMCSS;
Games, Audio, Playback e altri profili sono attività MMCSS.

L’applicazione associa il thread corrente a un’attività tramite AvSetMmThreadCharacteristics, modifica la priorità relativa tramite AvSetMmThreadPriority e annulla la registrazione tramite AvRevertMmThreadCharacteristics.

La documentazione non definisce il comportamento di un Registry value assente. Il suo risultato riportato di seguito è un’osservazione valida solo per la build verificata.

Metodologia

La metrica principale è il p99 della latenza di avvio del lavoro periodico nel profilo Games a quattro vCPU completamente caricate. Una singola esecuzione indipendente corrispondeva a uno stato dopo un caricamento separato di Windows. All’interno di ogni esecuzione venivano eseguiti 2500 periodi, ma non erano considerati ripetizioni indipendenti.

Per ogni stato sono state condotte due serie da 10 caricamenti. L’ordine degli stati è stato bilanciato, gli outlier non sono stati rimossi. La soglia praticamente significativa è stata fissata in anticipo al livello 1.784 ms. Per la differenza con lo stato 20 è stato usato un bootstrap accoppiato con IC al 95%.

Le serie sono mostrate separatamente: nella seconda serie era attiva una sessione ETW aggiuntiva di sola validazione, assente nella prima. Non era la fonte della metrica principale, ma il secondo blocco si è rivelato più rumoroso, quindi il numero combinato di 20 esecuzioni avrebbe potuto nascondere la non omogeneità dei dati.

La verifica separata del meccanismo comprendeva quattro caricamenti per 10, 20, 100 e il valore assente. Lo stesso thread è stato misurato prima del tentativo di registrazione MMCSS, dopo di esso e dopo il cleanup. Sono stati verificati l’esito della registrazione, la Win32 thread priority e la priorità effettiva dello scheduler tramite ETW. Tutte le 16 esecuzioni principali sono state accettate; in questa serie non ci sono stati ETW events o buffers persi. I pilot infrastrutturali non sono stati inclusi nei risultati.

Risultati

Come Windows ha gestito i valori

Registrato	Stato osservato dopo il caricamento	Risultato
assente	MMCSS arrestato, registrazione non eseguita, l’API ha restituito 100	osservazione separata per questa build
`0`, `1`, `9`	l’API ha restituito 20, MMCSS in esecuzione	normalizzato a 20
`10`	l’API ha restituito 10, MMCSS in esecuzione	valore utilizzato
`11`, `19`	l’API ha restituito 10, MMCSS in esecuzione	arrotondato per difetto
`20`	l’API ha restituito 20, MMCSS in esecuzione	valore utilizzato
`21`	l’API ha restituito 20, MMCSS in esecuzione	arrotondato per difetto
`99`	l’API ha restituito 90, MMCSS in esecuzione	arrotondato per difetto
`100`	MMCSS arrestato, registrazione non eseguita	disattivazione documentata
`101`, `0xFFFFFFFF`	l’API ha restituito 20, MMCSS in esecuzione	normalizzato a 20

Per i valori numerici la mappa ha coinciso con la documentazione Microsoft. Con il value assente il numero 100 è stato restituito senza una registrazione MMCSS valida, quindi è indicato come API fallback e non come risultato di una richiesta a un MMCSS in esecuzione. Lo stato disattivato in questa build è stato confermato separatamente tramite il servizio e la registrazione, ma non può essere trasferito automaticamente ad altre versioni di Windows.

L’applicazione affidabile del nuovo stato è stata osservata dopo il riavvio. La modifica del Registry non ha cambiato lo stato di un MMCSS handle già aperto o di un nuovo processo nel caricamento corrente. Un tentativo fallito di arresto e avvio del servizio non è considerato un metodo di applicazione supportato.

p99 della latenza sintetica

Una differenza positiva indica una latenza p99 più alta, cioè peggiore, rispetto a 20.

Confronto con `20`	Serie 1, differenza e IC al 95%	Serie 2, differenza e IC al 95%	Conclusione
`10`	`+0.625 ms` `[-1.111; +2.474]`	`+0.975 ms` `[-3.579; +5.613]`	vantaggio non stabilito; equivalenza non dimostrata
`0`	`+1.267 ms` `[-0.014; +2.564]`	`-1.902 ms` `[-4.681; +0.718]`	risultato indeterminato e variabile per direzione
`100`	`+10.812 ms` `[+8.787; +12.915]`	`+12.074 ms` `[+9.669; +14.127]`	danno praticamente significativo nel proxy sintetico
assente	`+11.640 ms` `[+9.690; +13.480]`	`+12.494 ms` `[+9.303; +16.208]`	danno praticamente significativo nel proxy sintetico

10 non ha mostrato un vantaggio praticamente significativo rispetto a 20 in nessuna delle due serie. L’ampio intervallo della seconda serie ammette sia un beneficio sia un danno, quindi il risultato non può essere definito una prova di equivalenza.

Cosa è cambiato con MMCSS disattivato

Stato	Registrazione	Stato MMCSS	Win32 priority di un thread	ETW priority di un thread
`20`	4/4	in esecuzione	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`10`	4/4	in esecuzione	`0 -> 10 -> 0`	`8 -> 18 -> 8`
`100`	0/4	arrestato	`0 -> 0 -> 0`	`8 -> 8 -> 8`
assente	0/4	arrestato	`0 -> 0 -> 0`	`8 -> 8 -> 8`

La sequenza nelle ultime due colonne indica lo stato prima della registrazione, dopo il tentativo di registrazione e dopo il cleanup. La Process priority class non è cambiata.

Ciò conferma direttamente una causa del peggioramento della metrica sintetica: con MMCSS disattivato il thread di test continuava lo stesso lavoro, ma non riceveva l’aumento di priorità. Il contributo separato della CPU quota e di altre regole di accounting delle risorse non è stato isolato.

100 e il valore assente hanno coinciso per stato del servizio, esito della registrazione e priorità del thread. Ciò non dimostra la loro piena equivalenza in tutti gli scenari interni e utente.

Cosa è confermato

SystemResponsiveness modifica lo stato osservabile di MMCSS dopo il caricamento di Windows.
0 non crea uno stato effettivo 0, ma viene normalizzato a 20.
10 e 20 consentono la registrazione del thread e in questo test producono la stessa transizione della sua priorità.
Un vantaggio praticamente significativo di 10 rispetto a 20 secondo la metrica p99 scelta non è stato stabilito.
100 disattiva MMCSS; nella build verificata lo stesso stato è stato osservato con il value assente.
Con MMCSS disattivato il thread di test non ha ricevuto l’aumento di priorità e la latenza p99 sintetica è peggiorata in entrambe le serie.

Cosa non è confermato

Che 10 e 20 siano equivalenti per tutti i workload MMCSS.
Che 10 aumenti gli FPS, riduca l’input latency o migliori l’audio.
Che 100 causi necessariamente audio glitches, disallineamenti o problemi in un gioco specifico.
Che l’osservazione per il value assente si ripeta su un’altra build di Windows.
Che i millisecondi ottenuti siano una latenza end-to-end fisica.
Che il risultato della macchina virtuale sia trasferibile a un PC fisico.

Limitazioni

Lo studio è stato eseguito su una singola VMware VM e una singola build di Windows. Il profilo sintetico Games crea una contesa controllata per la CPU, ma non riproduce un motore di gioco, un driver audio, una pipeline di input reale o il display scanout.

Nella seconda serie la sessione ETW aggiuntiva è stata usata solo per la validazione, ma potrebbe aver modificato il livello di rumore complessivo. Per questo le due serie non sono state unite in un’unica stima. La verifica del meccanismo mostra la perdita dell’aumento di priorità, ma non separa il possibile contributo della MMCSS quota e della accounting policy.

Non sono stati misurati test audio fisici, FPS, frametime, click-to-photon e input latency. Non esiste ancora una ripetizione indipendente su un’altra macchina o build.

Conclusione pratica

Non usate 0 come modo per impostare una «riserva zero»: Windows lo porta a 20. Non considerate 10 come un valore universale dimostrabilmente migliore: in questa VM il vantaggio rispetto a 20 non è stato stabilito.

Non usate 100 e non eliminate il valore per «disattivare le limitazioni». Nell’ambiente verificato ciò ha disattivato MMCSS, privato il thread dell’aumento di priorità e peggiorato in modo evidente la latenza p99 sintetica. Senza un test fisico separato questa conclusione non può essere trasformata in una previsione precisa di FPS o audio.

Per un sistema normale la conclusione sicura si limita a mantenere lo stato predefinito di Windows. Una modifica è giustificata solo con una metrica utente scelta in anticipo, misurazioni accoppiate ripetute e un ripristino confermato.

Ripristino dello stato

La raccomandazione sintetica per l’utente e lo stato esatto del registro sono pubblicati nella pagina «SystemResponsiveness».

Dopo ogni fase sperimentale la VM è stata riportata allo stato iniziale protetto. Un caricamento di controllo ha confermato il Registry value 20, MMCSS in esecuzione, l’assenza di tracciature attive e la conclusione dei processi di test. Dopo la verifica è stato eseguito un ulteriore ripristino e la VM è stata lasciata spenta.

Fonti primarie pubbliche

Multimedia Class Scheduler Service, Microsoft Learn - scopo di MMCSS, SystemResponsiveness, arrotondamento e disattivazione a 100.
AvSetMmThreadCharacteristicsW, Microsoft Learn - registrazione del thread corrente in un’attività MMCSS.
AvSetMmThreadPriority, Microsoft Learn - priorità relativa del thread registrato.
AvRevertMmThreadCharacteristics, Microsoft Learn - conclusione della registrazione del thread.
KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Fonti pubbliche e formulazioni verificate: 2026-08-25.

Lo studio e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, quindi lo sviluppatore ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate tramite i dati aperti e le fonti pubbliche elencate. La presenza del parametro nel prodotto non è stata usata come prova; il risultato indeterminato per 10 e il risultato negativo della disattivazione di MMCSS sono stati conservati senza selezione.

BoosterX Wiki è una pubblicazione indipendente e non è affiliata, autorizzata, sponsorizzata o approvata da Microsoft Corporation.

Cronologia delle modifiche

2026-09-20: il disclaimer sul conflitto di interessi è stato rafforzato fino alla formulazione completa con l’appartenenza dello studio e degli strumenti.
2026-08-25: prima pubblicazione; aggiunte due serie separate di p99, la verifica della priorità del thread, i limiti per audio e giochi, nonché il ripristino confermato dello stato.