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 של השהיה ב-workload סינתטי של MMCSS בעומס 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 מזווג.

הסדרות מוצגות בנפרד: בסדרה השנייה פעלה הפעלת ETW נוספת ל-validation בלבד, שלא הייתה בראשונה. היא לא הייתה מקור המדד העיקרי, אך הבלוק השני התברר כרועש יותר, ולכן המספר המאוחד של 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 נוספת שימשה רק ל-validation, אך הייתה עשויה לשנות את רמת הרעש הכללית. לכן שתי הסדרות לא אוחדו להערכה אחת. בדיקת המנגנון מראה אובדן העלאת עדיפות, אך אינה מפרידה את התרומה האפשרית של MMCSS quota ושל accounting policy.

מבחן אודיו פיזי, FPS, frametime, click-to-photon ו-input latency לא נמדדו. אין עדיין שחזור עצמאי במכונה או במהדורה אחרת.

מסקנה מעשית

אל תשתמשו ב-0 כדרך לקבוע «רזרבה אפס»: Windows מנרמלת אותו ל-20. אל תתייחסו ל-10 כאל ערך אוניברסלי טוב יותר מוכח: ב-VM הזו יתרון על פני 20 לא הוכח.

אל תשתמשו ב-100 ואל תמחקו את הערך כדי «לכבות הגבלות». בסביבה הנבדקת הדבר כיבה את MMCSS, שלל מהתהליכון העלאת עדיפות והרע באופן ניכר את השהיית ה-p99 הסינתטית. בלי מבחן פיזי נפרד אין להפוך את המסקנה הזו לתחזית מדויקת של FPS או אודיו.

עבור מערכת רגילה המסקנה הבטוחה מוגבלת לשמירה על מצב ברירת המחדל של Windows. שינוי מוצדק רק עם מדד משתמש שנבחר מראש, מדידות מזווגות חוזרות וחזרה מאומתת.

שחזור המצב

המלצת משתמש קצרה והמצב המדויק ב-Registry פורסמו בעמוד «SystemResponsiveness».

לאחר כל שלב ניסוי ה-VM חזרה למצב ההתחלתי המוגן. אתחול בקרה אישר Registry value 20, MMCSS פעיל, היעדר tracing פעיל וסיום תהליכי הבדיקה. לאחר הבדיקה בוצעה חזרה נוספת, וה-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 נפרדות, בדיקת עדיפות התהליכון, גבולות לאודיו ולמשחקים, וכן שחזור מצב מאומת.