SystemResponsiveness і MMCSS: що роблять значення 0, 10, 20 і 100

Коротка відповідь

У BoosterX цей параметр представлений налаштуванням «SystemResponsiveness». Значення 10 змінює резерв MMCSS, але перевага над 20 у перевіреному сценарії не встановлена; 100 вимикає MMCSS.

SystemResponsiveness не є плацебо. Це параметр MMCSS, який Windows нормалізує та застосовує під час завантаження. У дослідженій Windows 11 значення 0 дало той самий ефективний стан 20, а 10 змінило стан MMCSS, але не показало переваги над 20 у синтетичному тесті планувальника.

Значення 100 вимкнуло MMCSS. Реєстрація потоку не виконувалася, потік не отримував підвищення пріоритету, а p99 затримки синтетичного планувального workload зросла приблизно на 11-12 ms відносно 20. Такий результат не означає, що Windows загалом стала повільнішою на 60%, і не доводить погіршення FPS, input latency чи реального звуку.

Пов’язані налаштування BoosterX

Практична сторінка налаштування: «Резерв CPU для фонових задач».

Твердження, що перевіряється

Дослідження перевіряло три окремі твердження:

1. Чи змінюють 0, 10, 20, 100 і відсутнє значення фактичний стан MMCSS після завантаження.
2. Чи дає 10 практично значущу перевагу над 20 за p99 затримки синтетичного MMCSS workload при повному завантаженні CPU.
3. Чи пояснюється результат при вимкненому MMCSS втратою підвищення пріоритету в зареєстрованого потоку.

Навіть підтверджена зміна механізму та синтетичної метрики не доводить вплив на користувацьку затримку, звук чи продуктивність гри.

Область дослідження

• Windows 11 Pro 25H2 x64, build 26200.9168.
• VMware VM: 4 vCPU, 8 GB RAM, план живлення Balanced.
• Основні стани: відсутнє значення, 0, 10, 20 і 100.
• Додаткова перевірка меж: 1, 9, 11, 19, 21, 99, 101 і 0xFFFFFFFF.
• Результат стосується однієї віртуальної машини та однієї збірки Windows.

Збірку підтверджено сторінкою оновлення KB5121003 Microsoft Support.

Що документує Microsoft

Microsoft описує MMCSS як механізм, який дає змогу time-sensitive multimedia workload отримувати пріоритетний доступ до CPU без повного витіснення роботи з нижчим пріоритетом. Параметр SystemResponsiveness зберігається в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

У документації MMCSS зазначено:

• значення, не кратні 10, округлюються вниз до найближчого десятка;
• значення нижче 10 і вище 100 приводяться до 20;
• значення 100 вимикає MMCSS;
• Games, Audio, Playback та інші профілі є задачами MMCSS.

Застосунок пов’язує поточний потік із задачею через AvSetMmThreadCharacteristics, змінює відносний пріоритет через AvSetMmThreadPriority і скасовує реєстрацію через AvRevertMmThreadCharacteristics.

Документація не задає поведінку відсутнього Registry value. Його результат нижче є спостереженням лише для перевіреної збірки.

Методика

Основна метрика - p99 затримки запуску періодичної роботи в профілі Games при повному завантаженні чотирьох vCPU. Один незалежний прогін відповідав одному стану після окремого завантаження Windows. Усередині кожного прогону виконувалося 2500 періодів, але вони не вважалися незалежними повторами.

Для кожного стану проведено дві серії по 10 завантажень. Порядок станів балансувався, викиди не видалялися. Практично значущий поріг було встановлено заздалегідь на рівні 1.784 ms. Для різниці зі станом 20 використано парний bootstrap 95% CI.

Серії показано окремо: у другій серії працювала додаткова validation-only ETW-сесія, якої не було в першій. Вона не була джерелом основної метрики, але другий блок виявився шумнішим, тому об’єднане число з 20 прогонів могло б приховати неоднорідність даних.

Окрема перевірка механізму включала по чотири завантаження для 10, 20, 100 і відсутнього значення. Один і той самий потік вимірювався до спроби реєстрації MMCSS, після неї та після cleanup. Перевірялися результат реєстрації, Win32 thread priority і фактичний пріоритет планувальника за ETW. Усі 16 основних прогонів прийнято; втрачених ETW events або buffers у цій серії не було. Інфраструктурні пілоти до результатів не включалися.

Результати

Як Windows обробила значення

Записано	Спостережуваний стан після завантаження	Результат
відсутнє	MMCSS зупинено, реєстрацію не виконано, API повернув 100	окреме спостереження для цієї збірки
0, 1, 9	API повернув 20, MMCSS працює	нормалізовано до 20
10	API повернув 10, MMCSS працює	значення використовується
11, 19	API повернув 10, MMCSS працює	округлено вниз
20	API повернув 20, MMCSS працює	значення використовується
21	API повернув 20, MMCSS працює	округлено вниз
99	API повернув 90, MMCSS працює	округлено вниз
100	MMCSS зупинено, реєстрацію не виконано	документоване вимкнення
101, 0xFFFFFFFF	API повернув 20, MMCSS працює	нормалізовано до 20

Для числових значень карта збіглася з документацією Microsoft. За відсутнього value число 100 повернулося без валідної реєстрації MMCSS, тому його вказано як API fallback, а не як результат запиту до працюючого MMCSS. Вимкнений стан у цій збірці підтверджувався окремо за службою та реєстрацією, але його не можна автоматично переносити на інші версії Windows.

Надійне застосування нового стану спостерігалося після перезавантаження. Зміна Registry не змінила стан уже відкритого MMCSS handle або нового процесу в поточному завантаженні. Невдала спроба зупинки та запуску служби не вважається підтриманим способом застосування.

p99 синтетичної затримки

Позитивна різниця означає вищу, тобто гіршу, p99 затримку відносно 20.

Порівняння з 20	Серія 1, різниця та 95% CI	Серія 2, різниця та 95% CI	Висновок
10	+0.625 ms [-1.111; +2.474]	+0.975 ms [-3.579; +5.613]	перевагу не встановлено; еквівалентність не доведено
0	+1.267 ms [-0.014; +2.564]	-1.902 ms [-4.681; +0.718]	результат невизначений і різниться за напрямком
100	+10.812 ms [+8.787; +12.915]	+12.074 ms [+9.669; +14.127]	практично значуща шкода в синтетичному proxy
відсутнє	+11.640 ms [+9.690; +13.480]	+12.494 ms [+9.303; +16.208]	практично значуща шкода в синтетичному proxy

10 не показало практично значущої переваги над 20 в жодній серії. Широкий інтервал другої серії допускає як користь, так і шкоду, тому результат не можна називати доказом еквівалентності.

Що змінилося при вимкненні MMCSS

Стан	Реєстрація	Стан MMCSS	Win32 priority одного потоку	ETW priority одного потоку
20	4/4	працює	0 -> 10 -> 0	8 -> 18 -> 8
10	4/4	працює	0 -> 10 -> 0	8 -> 18 -> 8
100	0/4	зупинено	0 -> 0 -> 0	8 -> 8 -> 8
відсутнє	0/4	зупинено	0 -> 0 -> 0	8 -> 8 -> 8

Послідовність у двох останніх стовпцях означає стан до реєстрації, після спроби реєстрації та після cleanup. Process priority class не змінювався.

Це напряму підтверджує одну причину погіршення синтетичної метрики: при вимкненому MMCSS тестовий потік продовжував ту саму роботу, але не отримував підвищення пріоритету. Окремий внесок CPU quota та інших правил обліку ресурсів не ізольовано.

100 і відсутнє значення збіглися за станом служби, результатом реєстрації та пріоритетом потоку. Це не доводить їхню повну еквівалентність у всіх внутрішніх і користувацьких сценаріях.

Що підтверджено

• SystemResponsiveness змінює спостережуваний стан MMCSS після завантаження Windows.
• 0 не створює ефективний стан 0, а нормалізується до 20.
• 10 і 20 допускають реєстрацію потоку і в цьому тесті дають однаковий перехід його пріоритету.
• Практично значущу перевагу 10 над 20 за обраною p99 метрикою не встановлено.
• 100 вимикає MMCSS; у перевіреній збірці той самий стан спостерігався за відсутнього value.
• У вимкненого MMCSS тестовий потік не отримав підвищення пріоритету, а синтетична p99 затримка погіршилася в обох серіях.

Що не підтверджено

• Що 10 і 20 еквівалентні для всіх MMCSS workload.
• Що 10 підвищує FPS, зменшує input latency або покращує звук.
• Що 100 обов’язково спричиняє audio glitches, розсинхронізацію або проблеми в конкретній грі.
• Що спостереження для відсутнього value повторюється на іншій збірці Windows.
• Що отримані мілісекунди є фізичною end-to-end latency.
• Що результат віртуальної машини переноситься на фізичний ПК.

Обмеження

Дослідження виконано на одній VMware VM і одній збірці Windows. Синтетичний профіль Games створює керовану конкуренцію за CPU, але не відтворює ігровий рушій, аудіодрайвер, реальний input pipeline або display scanout.

У другій серії додаткова ETW-сесія використовувалася лише для валідації, але могла змінити загальний рівень шуму. Тому дві серії не об’єднано в одну оцінку. Механізм-перевірка показує втрату підвищення пріоритету, але не відокремлює можливий внесок MMCSS quota та accounting policy.

Фізичний аудіотест, FPS, frametime, click-to-photon та input latency не вимірювалися. Незалежного повторення на іншій машині чи збірці поки немає.

Практичний висновок

Не використовуйте 0 як спосіб задати «нульовий резерв»: Windows приводить його до 20. Не розглядайте 10 як доведено краще універсальне значення: у цій VM перевагу над 20 не встановлено.

Не використовуйте 100 і не видаляйте значення заради «вимкнення обмежень». У перевіреному середовищі це вимкнуло MMCSS, позбавило потік підвищення пріоритету та помітно погіршило синтетичну p99 затримку. Без окремого фізичного тесту не можна перетворювати цей висновок на точний прогноз FPS чи звуку.

Для звичайної системи безпечний висновок обмежений збереженням штатного стану Windows. Зміна виправдана лише за заздалегідь обраної користувацької метрики, повторних парних вимірювань і підтвердженого повернення.

Відновлення стану

Коротка користувацька рекомендація та точний стан реєстру опубліковані на сторінці «SystemResponsiveness».

Після кожної експериментальної фази VM поверталася до захищеного вихідного стану. Контрольне завантаження підтвердило Registry value 20, працюючий MMCSS, відсутність активної трасування та завершення тестових процесів. Після перевірки виконано повторне повернення, VM залишено вимкненою.

Публічні первинні джерела

• Multimedia Class Scheduler Service, Microsoft Learn - призначення MMCSS, SystemResponsiveness, округлення та вимкнення при 100.
• AvSetMmThreadCharacteristicsW, Microsoft Learn - реєстрація поточного потоку в задачі MMCSS.
• AvSetMmThreadPriority, Microsoft Learn - відносний пріоритет зареєстрованого потоку.
• AvRevertMmThreadCharacteristics, Microsoft Learn - завершення реєстрації потоку.
• KB5121003, Microsoft Support - Windows 11 build 26200.9168.

Публічні джерела та формулювання перевірено: 2026-08-25.

Дослідження та використані інструменти належать розробнику BoosterX, тому в розробника є прямий інтерес до результатів. Методику та межі застосовності описано вище, а висновки можна перевірити за відкритими даними та переліченими публічними джерелами. Наявність параметра в продукті не використовувалася як доказ; невизначений результат для 10 і негативний результат вимкнення MMCSS збережено без відбору.

BoosterX Wiki є незалежною публікацією і не пов’язана, не авторизована, не спонсорується та не схвалена Microsoft Corporation.

Історія змін

• 2026-09-20: дисклеймер про конфлікт інтересів посилено до повного формулювання з належністю дослідження та інструментів.
• 2026-08-25: перша публікація; додано дві роздільні серії p99, перевірку пріоритету потоку, межі для аудіо та ігор, а також підтверджене відновлення стану.