Lewati ke konten

SystemResponsiveness dan MMCSS: apa fungsi nilai 0, 10, 20, dan 100

Di halaman ini

Di BoosterX, parameter ini disajikan sebagai pengaturan «SystemResponsiveness». Nilai 10 mengubah cadangan MMCSS, tetapi keunggulan atas 20 dalam skenario yang diuji tidak terbukti; 100 menonaktifkan MMCSS.

SystemResponsiveness bukan plasebo. Ini adalah parameter MMCSS yang dinormalisasi dan diterapkan oleh Windows saat boot. Pada Windows 11 yang diteliti, nilai 0 menghasilkan keadaan efektif 20 yang sama, dan 10 mengubah keadaan MMCSS, tetapi tidak menunjukkan keunggulan atas 20 dalam uji sintetis scheduler.

Nilai 100 menonaktifkan MMCSS. Registrasi thread tidak dilakukan, thread tidak menerima peningkatan prioritas, dan p99 latensi workload penjadwalan sintetis naik sekitar 11-12 ms dibandingkan 20. Hasil ini tidak berarti Windows secara keseluruhan menjadi 60% lebih lambat, dan tidak membuktikan penurunan FPS, input latency, atau audio nyata.

Halaman pengaturan praktis: «Cadangan CPU untuk tugas latar belakang».

Penelitian menguji tiga klaim terpisah:

  1. Apakah 0, 10, 20, 100 dan nilai yang tidak ada mengubah keadaan MMCSS yang sebenarnya setelah boot.
  2. Apakah 10 memberikan keunggulan yang signifikan secara praktis atas 20 pada p99 latensi workload MMCSS sintetis saat CPU terisi penuh.
  3. Apakah hasil saat MMCSS dinonaktifkan dijelaskan oleh hilangnya peningkatan prioritas pada thread yang terdaftar.

Bahkan perubahan mekanisme dan metrik sintetis yang terkonfirmasi tidak membuktikan pengaruhnya terhadap latensi pengguna, audio, atau performa game.

  • Windows 11 Pro 25H2 x64, build 26200.9168.
  • VMware VM: 4 vCPU, 8 GB RAM, power plan Balanced.
  • Keadaan utama: nilai yang tidak ada, 0, 10, 20 dan 100.
  • Pemeriksaan batas tambahan: 1, 9, 11, 19, 21, 99, 101 dan 0xFFFFFFFF.
  • Hasil berlaku untuk satu mesin virtual dan satu build Windows.

Build dikonfirmasi oleh halaman pembaruan KB5121003 Microsoft Support.

Microsoft mendeskripsikan MMCSS sebagai mekanisme yang memungkinkan workload multimedia yang sensitif terhadap waktu mendapatkan akses prioritas ke CPU tanpa sepenuhnya menggeser pekerjaan berprioritas lebih rendah. Parameter SystemResponsiveness disimpan di HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile.

Dalam dokumentasi MMCSS disebutkan:

  • nilai yang bukan kelipatan 10 dibulatkan ke bawah ke puluhan terdekat;
  • nilai di bawah 10 dan di atas 100 disesuaikan menjadi 20;
  • nilai 100 menonaktifkan MMCSS;
  • Games, Audio, Playback dan profil lain adalah tugas MMCSS.

Aplikasi mengaitkan thread saat ini dengan tugas melalui AvSetMmThreadCharacteristics, mengubah prioritas relatif melalui AvSetMmThreadPriority dan membatalkan registrasi melalui AvRevertMmThreadCharacteristics.

Dokumentasi tidak menetapkan perilaku Registry value yang tidak ada. Hasilnya di bawah ini merupakan pengamatan hanya untuk build yang diuji.

Metrik utama adalah p99 latensi dimulainya pekerjaan periodik pada profil Games saat keempat vCPU terisi penuh. Satu run independen sesuai dengan satu keadaan setelah boot Windows terpisah. Di dalam setiap run dilakukan 2500 periode, tetapi periode tersebut tidak dianggap sebagai pengulangan independen.

Untuk setiap keadaan dilakukan dua seri masing-masing 10 boot. Urutan keadaan diseimbangkan, outlier tidak dihapus. Ambang signifikan secara praktis ditetapkan sebelumnya pada tingkat 1.784 ms. Untuk selisih dengan keadaan 20 digunakan paired bootstrap 95% CI.

Seri ditampilkan secara terpisah: pada seri kedua berjalan sesi ETW tambahan khusus validasi yang tidak ada pada seri pertama. Sesi itu bukan sumber metrik utama, tetapi blok kedua ternyata lebih bising, sehingga jumlah gabungan dari 20 run bisa menyembunyikan ketidakhomogenan data.

Pemeriksaan mekanisme terpisah mencakup masing-masing empat boot untuk 10, 20, 100 dan nilai yang tidak ada. Thread yang sama diukur sebelum upaya registrasi MMCSS, setelahnya dan setelah cleanup. Diperiksa hasil registrasi, Win32 thread priority dan prioritas scheduler aktual menurut ETW. Semua 16 run utama diterima; tidak ada ETW event atau buffer yang hilang pada seri ini. Pilot infrastruktur tidak dimasukkan ke dalam hasil.

Tertulis Keadaan yang teramati setelah boot Hasil
tidak ada MMCSS dihentikan, registrasi tidak dilakukan, API mengembalikan 100 pengamatan terpisah untuk build ini
0, 1, 9 API mengembalikan 20, MMCSS berjalan dinormalisasi menjadi 20
10 API mengembalikan 10, MMCSS berjalan nilai digunakan
11, 19 API mengembalikan 10, MMCSS berjalan dibulatkan ke bawah
20 API mengembalikan 20, MMCSS berjalan nilai digunakan
21 API mengembalikan 20, MMCSS berjalan dibulatkan ke bawah
99 API mengembalikan 90, MMCSS berjalan dibulatkan ke bawah
100 MMCSS dihentikan, registrasi tidak dilakukan penonaktifan yang didokumentasikan
101, 0xFFFFFFFF API mengembalikan 20, MMCSS berjalan dinormalisasi menjadi 20

Untuk nilai numerik, peta cocok dengan dokumentasi Microsoft. Pada value yang tidak ada, angka 100 dikembalikan tanpa registrasi MMCSS yang valid, sehingga dicatat sebagai API fallback, bukan sebagai hasil kueri ke MMCSS yang berjalan. Keadaan nonaktif pada build ini dikonfirmasi secara terpisah melalui service dan registrasi, tetapi tidak dapat secara otomatis diterapkan ke versi Windows lain.

Penerapan keadaan baru yang andal teramati setelah reboot. Perubahan Registry tidak mengubah keadaan MMCSS handle yang sudah terbuka atau proses baru pada boot saat ini. Upaya gagal menghentikan dan memulai service tidak dianggap sebagai cara penerapan yang didukung.

Selisih positif berarti p99 latensi yang lebih tinggi, yaitu lebih buruk, dibandingkan 20.

Perbandingan dengan 20 Seri 1, selisih dan 95% CI Seri 2, selisih dan 95% CI Kesimpulan
10 +0.625 ms [-1.111; +2.474] +0.975 ms [-3.579; +5.613] keunggulan tidak terbukti; ekuivalensi tidak dibuktikan
0 +1.267 ms [-0.014; +2.564] -1.902 ms [-4.681; +0.718] hasil tidak pasti dan berbeda arah
100 +10.812 ms [+8.787; +12.915] +12.074 ms [+9.669; +14.127] kerugian yang signifikan secara praktis pada proxy sintetis
tidak ada +11.640 ms [+9.690; +13.480] +12.494 ms [+9.303; +16.208] kerugian yang signifikan secara praktis pada proxy sintetis

10 tidak menunjukkan keunggulan yang signifikan secara praktis atas 20 pada seri mana pun. Interval lebar pada seri kedua memungkinkan baik manfaat maupun kerugian, sehingga hasilnya tidak dapat disebut sebagai bukti ekuivalensi.

Keadaan Registrasi Keadaan MMCSS Win32 priority satu thread ETW priority satu thread
20 4/4 berjalan 0 -> 10 -> 0 8 -> 18 -> 8
10 4/4 berjalan 0 -> 10 -> 0 8 -> 18 -> 8
100 0/4 dihentikan 0 -> 0 -> 0 8 -> 8 -> 8
tidak ada 0/4 dihentikan 0 -> 0 -> 0 8 -> 8 -> 8

Urutan pada dua kolom terakhir berarti keadaan sebelum registrasi, setelah upaya registrasi dan setelah cleanup. Process priority class tidak berubah.

Ini secara langsung mengonfirmasi satu penyebab memburuknya metrik sintetis: saat MMCSS dinonaktifkan, thread uji melanjutkan pekerjaan yang sama, tetapi tidak menerima peningkatan prioritas. Kontribusi terpisah dari CPU quota dan aturan akuntansi sumber daya lainnya tidak diisolasi.

100 dan nilai yang tidak ada sama dalam keadaan service, hasil registrasi dan prioritas thread. Ini tidak membuktikan ekuivalensi penuhnya di semua skenario internal dan pengguna.

  • SystemResponsiveness mengubah keadaan MMCSS yang teramati setelah boot Windows.
  • 0 tidak menciptakan keadaan efektif 0, melainkan dinormalisasi menjadi 20.
  • 10 dan 20 memungkinkan registrasi thread dan dalam uji ini memberikan transisi prioritasnya yang sama.
  • Keunggulan yang signifikan secara praktis dari 10 atas 20 pada metrik p99 yang dipilih tidak terbukti.
  • 100 menonaktifkan MMCSS; pada build yang diuji keadaan yang sama teramati pada value yang tidak ada.
  • Pada MMCSS yang dinonaktifkan, thread uji tidak menerima peningkatan prioritas, dan p99 latensi sintetis memburuk pada kedua seri.
  • Bahwa 10 dan 20 ekuivalen untuk semua workload MMCSS.
  • Bahwa 10 meningkatkan FPS, mengurangi input latency atau memperbaiki audio.
  • Bahwa 100 pasti menyebabkan audio glitches, desinkronisasi atau masalah pada game tertentu.
  • Bahwa pengamatan untuk value yang tidak ada terulang pada build Windows lain.
  • Bahwa milidetik yang diperoleh merupakan end-to-end latency fisik.
  • Bahwa hasil mesin virtual berlaku untuk PC fisik.

Penelitian dilakukan pada satu VMware VM dan satu build Windows. Profil sintetis Games menciptakan persaingan terkendali untuk CPU, tetapi tidak mereproduksi game engine, audio driver, input pipeline nyata atau display scanout.

Pada seri kedua, sesi ETW tambahan hanya digunakan untuk validasi, tetapi dapat mengubah tingkat kebisingan keseluruhan. Karena itu kedua seri tidak digabungkan menjadi satu estimasi. Pemeriksaan mekanisme menunjukkan hilangnya peningkatan prioritas, tetapi tidak memisahkan kemungkinan kontribusi MMCSS quota dan accounting policy.

Audio test fisik, FPS, frametime, click-to-photon dan input latency tidak diukur. Belum ada pengulangan independen pada mesin atau build lain.

Jangan gunakan 0 sebagai cara menetapkan «cadangan nol»: Windows menyesuaikannya menjadi 20. Jangan anggap 10 sebagai nilai universal yang terbukti lebih baik: pada VM ini keunggulan atas 20 tidak terbukti.

Jangan gunakan 100 dan jangan hapus value demi «menonaktifkan pembatasan». Pada lingkungan yang diuji, ini menonaktifkan MMCSS, menghilangkan peningkatan prioritas thread dan secara nyata memperburuk p99 latensi sintetis. Tanpa uji fisik terpisah, kesimpulan ini tidak dapat diubah menjadi prediksi tepat untuk FPS atau audio.

Untuk sistem biasa, kesimpulan yang aman terbatas pada mempertahankan keadaan Windows bawaan. Perubahan hanya dibenarkan dengan metrik pengguna yang dipilih sebelumnya, pengukuran berpasangan berulang dan pemulihan yang terkonfirmasi.

Rekomendasi singkat untuk pengguna dan keadaan registry yang tepat dipublikasikan pada halaman «SystemResponsiveness».

Setelah setiap fase eksperimen, VM dikembalikan ke keadaan awal yang terlindungi. Boot kontrol mengonfirmasi Registry value 20, MMCSS yang berjalan, tidak adanya tracing aktif dan berakhirnya proses uji. Setelah pemeriksaan dilakukan pengembalian ulang, VM dibiarkan dimatikan.

Sumber publik dan perumusannya diverifikasi: 2026-08-25.

Penelitian dan alat yang digunakan dimiliki oleh pengembang BoosterX, sehingga pengembang memiliki kepentingan langsung terhadap hasilnya. Metodologi dan batas penerapannya dijelaskan di atas, dan kesimpulannya dapat diverifikasi melalui data terbuka dan sumber publik yang tercantum. Keberadaan parameter dalam produk tidak digunakan sebagai bukti; hasil yang tidak pasti untuk 10 dan hasil negatif dari penonaktifan MMCSS disimpan tanpa penyaringan.

BoosterX Wiki adalah publikasi independen dan tidak terkait, tidak diotorisasi, tidak disponsori dan tidak disetujui oleh Microsoft Corporation.

  • 2026-09-20: disclaimer tentang konflik kepentingan diperkuat menjadi perumusan lengkap dengan kepemilikan penelitian dan alat.
  • 2026-08-25: publikasi pertama; ditambahkan dua seri p99 terpisah, pemeriksaan prioritas thread, batas untuk audio dan game, serta pemulihan keadaan yang terkonfirmasi.