SystemResponsiveness i MMCSS: co robią wartości 0, 10, 20 i 100

Krótka odpowiedź

W BoosterX ten parametr jest reprezentowany przez ustawienie „SystemResponsiveness”. Wartość 10 zmienia rezerwę MMCSS, ale przewaga nad 20 w sprawdzonym scenariuszu nie została ustalona; 100 wyłącza MMCSS.

SystemResponsiveness nie jest placebo. To parametr MMCSS, który Windows normalizuje i stosuje przy rozruchu. W zbadanym Windows 11 wartość 0 dała ten sam efektywny stan 20, a 10 zmieniła stan MMCSS, ale nie wykazała przewagi nad 20 w syntetycznym teście planisty.

Wartość 100 wyłączyła MMCSS. Rejestracja wątku nie została wykonana, wątek nie otrzymał podwyższenia priorytetu, a p99 opóźnienia syntetycznego workloadu planistycznego wzrosło o około 11-12 ms względem 20. Taki wynik nie oznacza, że Windows jako całość stał się wolniejszy o 60%, i nie dowodzi pogorszenia FPS, input latency ani rzeczywistego dźwięku.

Powiązane ustawienia BoosterX

Praktyczna strona ustawienia: „Rezerwa CPU dla zadań w tle”.

Weryfikowane twierdzenie

Badanie weryfikowało trzy odrębne twierdzenia:

1. Czy 0, 10, 20, 100 i brakująca wartość zmieniają faktyczny stan MMCSS po rozruchu.
2. Czy 10 daje praktycznie istotną przewagę nad 20 pod względem p99 opóźnienia syntetycznego workloadu MMCSS przy pełnym obciążeniu CPU.
3. Czy wynik przy wyłączonym MMCSS tłumaczy się utratą podwyższenia priorytetu zarejestrowanego wątku.

Nawet potwierdzona zmiana mechanizmu i metryki syntetycznej nie dowodzi wpływu na opóźnienie odczuwane przez użytkownika, dźwięk ani wydajność gry.

Zakres badania

• Windows 11 Pro 25H2 x64, build 26200.9168.
• VMware VM: 4 vCPU, 8 GB RAM, plan zasilania Balanced.
• Główne stany: brakująca wartość, 0, 10, 20 i 100.
• Dodatkowa kontrola granic: 1, 9, 11, 19, 21, 99, 101 i 0xFFFFFFFF.
• Wynik dotyczy jednej maszyny wirtualnej i jednej kompilacji Windows.

Kompilację potwierdza strona aktualizacji KB5121003 Microsoft Support.

Co dokumentuje Microsoft

Microsoft opisuje MMCSS jako mechanizm, który pozwala time-sensitive multimedia workload uzyskać priorytetowy dostęp do CPU bez całkowitego wyparcia pracy o niższym priorytecie. Parametr SystemResponsiveness jest przechowywany w HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

W dokumentacji MMCSS podano:

• wartości niebędące wielokrotnością 10 są zaokrąglane w dół do najbliższej dziesiątki;
• wartości poniżej 10 i powyżej 100 są sprowadzane do 20;
• wartość 100 wyłącza MMCSS;
• Games, Audio, Playback i inne profile są zadaniami MMCSS.

Aplikacja wiąże bieżący wątek z zadaniem przez AvSetMmThreadCharacteristics, zmienia priorytet względny przez AvSetMmThreadPriority i wyrejestrowuje przez AvRevertMmThreadCharacteristics.

Dokumentacja nie określa zachowania brakującej wartości Registry. Jej wynik poniżej jest obserwacją wyłącznie dla sprawdzonej kompilacji.

Metodyka

Główna metryka to p99 opóźnienia uruchomienia pracy okresowej w profilu Games przy pełnym obciążeniu czterech vCPU. Jeden niezależny przebieg odpowiadał jednemu stanowi po osobnym rozruchu Windows. W ramach każdego przebiegu wykonano 2500 okresów, ale nie były one traktowane jako niezależne powtórzenia.

Dla każdego stanu przeprowadzono dwie serie po 10 rozruchów. Kolejność stanów była balansowana, wartości odstające nie były usuwane. Praktycznie istotny próg został z góry ustalony na poziomie 1.784 ms. Dla różnicy względem stanu 20 zastosowano sparowany bootstrap 95% CI.

Serie pokazano osobno: w drugiej serii działała dodatkowa sesja ETW wyłącznie walidacyjna, której nie było w pierwszej. Nie była źródłem głównej metryki, ale drugi blok okazał się bardziej szumny, więc połączona liczba z 20 przebiegów mogłaby ukryć niejednorodność danych.

Odrębna kontrola mechanizmu obejmowała po cztery rozruchy dla 10, 20, 100 i brakującej wartości. Ten sam wątek był mierzony przed próbą rejestracji MMCSS, po niej i po cleanup. Sprawdzano wynik rejestracji, Win32 thread priority i faktyczny priorytet planisty według ETW. Wszystkie 16 głównych przebiegów przyjęto; w tej serii nie było utraconych ETW events ani buffers. Infrastrukturalne piloty nie zostały włączone do wyników.

Wyniki

Jak Windows przetworzył wartości

Zapisano	Obserwowany stan po rozruchu	Wynik
brak	MMCSS zatrzymany, rejestracja niewykonana, API zwróciło 100	odrębna obserwacja dla tej kompilacji
0, 1, 9	API zwróciło 20, MMCSS działa	znormalizowano do 20
10	API zwróciło 10, MMCSS działa	wartość jest używana
11, 19	API zwróciło 10, MMCSS działa	zaokrąglono w dół
20	API zwróciło 20, MMCSS działa	wartość jest używana
21	API zwróciło 20, MMCSS działa	zaokrąglono w dół
99	API zwróciło 90, MMCSS działa	zaokrąglono w dół
100	MMCSS zatrzymany, rejestracja niewykonana	udokumentowane wyłączenie
101, 0xFFFFFFFF	API zwróciło 20, MMCSS działa	znormalizowano do 20

Dla wartości liczbowych mapa zgadzała się z dokumentacją Microsoft. Przy brakującej wartości liczba 100 zwróciła się bez ważnej rejestracji MMCSS, dlatego podano ją jako API fallback, a nie jako wynik zapytania do działającego MMCSS. Stan wyłączony w tej kompilacji był potwierdzany osobno przez usługę i rejestrację, ale nie można go automatycznie przenosić na inne wersje Windows.

Niezawodne zastosowanie nowego stanu zaobserwowano po ponownym rozruchu. Zmiana Registry nie zmieniła stanu już otwartego MMCSS handle ani nowego procesu w bieżącym rozruchu. Nieudana próba zatrzymania i uruchomienia usługi nie jest uznawana za wspierany sposób zastosowania.

p99 opóźnienia syntetycznego

Dodatnia różnica oznacza wyższe, czyli gorsze, p99 opóźnienie względem 20.

Porównanie z 20	Seria 1, różnica i 95% CI	Seria 2, różnica i 95% CI	Wniosek
10	+0.625 ms [-1.111; +2.474]	+0.975 ms [-3.579; +5.613]	przewagi nie ustalono; równoważności nie dowiedziono
0	+1.267 ms [-0.014; +2.564]	-1.902 ms [-4.681; +0.718]	wynik nieokreślony i różni się kierunkiem
100	+10.812 ms [+8.787; +12.915]	+12.074 ms [+9.669; +14.127]	praktycznie istotna szkoda w syntetycznym proxy
brak	+11.640 ms [+9.690; +13.480]	+12.494 ms [+9.303; +16.208]	praktycznie istotna szkoda w syntetycznym proxy

10 nie wykazało praktycznie istotnej przewagi nad 20 w żadnej serii. Szeroki przedział drugiej serii dopuszcza zarówno korzyść, jak i szkodę, dlatego wyniku nie można nazwać dowodem równoważności.

Co się zmieniło przy wyłączeniu MMCSS

Stan	Rejestracja	Stan MMCSS	Win32 priority jednego wątku	ETW priority jednego wątku
20	4/4	działa	0 -> 10 -> 0	8 -> 18 -> 8
10	4/4	działa	0 -> 10 -> 0	8 -> 18 -> 8
100	0/4	zatrzymany	0 -> 0 -> 0	8 -> 8 -> 8
brak	0/4	zatrzymany	0 -> 0 -> 0	8 -> 8 -> 8

Sekwencja w dwóch ostatnich kolumnach oznacza stan przed rejestracją, po próbie rejestracji i po cleanup. Process priority class nie zmieniał się.

To bezpośrednio potwierdza jedną przyczynę pogorszenia metryki syntetycznej: przy wyłączonym MMCSS wątek testowy wykonywał tę samą pracę, ale nie otrzymał podwyższenia priorytetu. Odrębny wkład CPU quota i innych reguł rozliczania zasobów nie został wyizolowany.

100 i brakująca wartość pokryły się pod względem stanu usługi, wyniku rejestracji i priorytetu wątku. To nie dowodzi ich pełnej równoważności we wszystkich wewnętrznych i użytkowych scenariuszach.

Co potwierdzono

• SystemResponsiveness zmienia obserwowany stan MMCSS po rozruchu Windows.
• 0 nie tworzy efektywnego stanu 0, lecz normalizuje się do 20.
• 10 i 20 dopuszczają rejestrację wątku i w tym teście dają identyczne przejście jego priorytetu.
• Praktycznie istotnej przewagi 10 nad 20 według wybranej metryki p99 nie ustalono.
• 100 wyłącza MMCSS; w sprawdzonej kompilacji ten sam stan zaobserwowano przy brakującej wartości.
• Przy wyłączonym MMCSS wątek testowy nie otrzymał podwyższenia priorytetu, a syntetyczne p99 opóźnienia pogorszyło się w obu seriach.

Co nie zostało potwierdzone

• Że 10 i 20 są równoważne dla wszystkich workloadów MMCSS.
• Że 10 podnosi FPS, zmniejsza input latency lub poprawia dźwięk.
• Że 100 z konieczności powoduje audio glitches, desynchronizację lub problemy w konkretnej grze.
• Że obserwacja dla brakującej wartości powtarza się na innej kompilacji Windows.
• Że uzyskane milisekundy są fizyczną end-to-end latency.
• Że wynik maszyny wirtualnej przenosi się na fizyczny PC.

Ograniczenia

Badanie wykonano na jednej VMware VM i jednej kompilacji Windows. Syntetyczny profil Games tworzy kontrolowaną konkurencję o CPU, ale nie odtwarza silnika gry, sterownika audio, rzeczywistego input pipeline ani display scanout.

W drugiej serii dodatkowa sesja ETW była używana wyłącznie do walidacji, ale mogła zmienić ogólny poziom szumu. Dlatego dwóch serii nie połączono w jedną ocenę. Kontrola mechanizmu pokazuje utratę podwyższenia priorytetu, ale nie oddziela możliwego wkładu MMCSS quota i accounting policy.

Fizyczny test audio, FPS, frametime, click-to-photon i input latency nie były mierzone. Niezależnego powtórzenia na innej maszynie lub kompilacji na razie nie ma.

Wniosek praktyczny

Nie używaj 0 jako sposobu ustawienia „zerowej rezerwy”: Windows sprowadza go do 20. Nie traktuj 10 jako dowiedzionie lepszej uniwersalnej wartości: w tej VM przewagi nad 20 nie ustalono.

Nie używaj 100 i nie usuwaj wartości w celu „wyłączenia ograniczeń”. W sprawdzonym środowisku wyłączyło to MMCSS, pozbawiło wątek podwyższenia priorytetu i wyraźnie pogorszyło syntetyczne p99 opóźnienia. Bez odrębnego fizycznego testu nie można zamienić tego wniosku w dokładną prognozę FPS lub dźwięku.

Dla zwykłego systemu bezpieczny wniosek ogranicza się do zachowania standardowego stanu Windows. Zmiana jest uzasadniona tylko przy z góry wybranej metryce użytkownika, powtarzanych sparowanych pomiarach i potwierdzonym powrocie.

Przywracanie stanu

Krótka rekomendacja dla użytkownika i dokładny stan rejestru zostały opublikowane na stronie „SystemResponsiveness”.

Po każdej fazie eksperymentalnej VM wracała do zabezpieczonego stanu początkowego. Kontrolny rozruch potwierdził Registry value 20, działający MMCSS, brak aktywnego śledzenia i zakończenie procesów testowych. Po sprawdzeniu wykonano ponowny powrót, VM pozostawiono wyłączoną.

Publiczne źródła pierwotne

• Multimedia Class Scheduler Service, Microsoft Learn - przeznaczenie MMCSS, SystemResponsiveness, zaokrąglanie i wyłączanie przy 100.
• AvSetMmThreadCharacteristicsW, Microsoft Learn - rejestracja bieżącego wątku w zadaniu MMCSS.
• AvSetMmThreadPriority, Microsoft Learn - priorytet względny zarejestrowanego wątku.
• AvRevertMmThreadCharacteristics, Microsoft Learn - zakończenie rejestracji wątku.
• KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Publiczne źródła i sformułowania sprawdzono: 2026-08-25.

Badanie i użyte narzędzia należą do dewelopera BoosterX, dlatego deweloper ma bezpośredni interes w wynikach. Metodyka i granice stosowalności opisano powyżej, a wnioski można zweryfikować na podstawie otwartych danych i wymienionych publicznych źródeł. Obecność parametru w produkcie nie była używana jako dowód; nieokreślony wynik dla 10 i negatywny wynik wyłączenia MMCSS zachowano bez selekcji.

BoosterX Wiki jest niezależną publikacją i nie jest związana, autoryzowana, sponsorowana ani zatwierdzona przez Microsoft Corporation.

Historia zmian

• 2026-09-20: disclaimer o konflikcie interesów wzmocniono do pełnego sformułowania z przynależnością badania i narzędzi.
• 2026-08-25: pierwsza publikacja; dodano dwie rozdzielne serie p99, kontrolę priorytetu wątku, granice dla audio i gier oraz potwierdzone przywracanie stanu.