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 को अक्षम कर दिया। थ्रेड का पंजीकरण नहीं हुआ, थ्रेड को प्राथमिकता बढ़ोतरी नहीं मिली, और सिंथेटिक शेड्यूलिंग workload की p99 विलंबता 20 के सापेक्ष लगभग 11-12 ms बढ़ गई। ऐसा परिणाम इसका अर्थ नहीं है कि Windows समग्र रूप से 60% धीमा हो गया, और यह FPS, input latency या वास्तविक ऑडियो के बिगड़ने को सिद्ध नहीं करता।

BoosterX की संबंधित सेटिंग्स

व्यावहारिक सेटिंग पृष्ठ: «पृष्ठभूमि कार्यों के लिए CPU आरक्षण»।

सत्यापन योग्य दावा

अध्ययन ने तीन अलग-अलग दावों की जाँच की:

क्या 0, 10, 20, 100 और अनुपस्थित मान बूट के बाद MMCSS की वास्तविक स्थिति बदलते हैं।
क्या 10 पूर्ण CPU लोड पर सिंथेटिक MMCSS workload की p99 विलंबता में 20 पर व्यावहारिक रूप से महत्वपूर्ण लाभ देता है।
क्या 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 बिल्ड पर लागू होता है।

बिल्ड की पुष्टि Microsoft Support के अपडेट पृष्ठ KB5121003 से होती है।

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 का व्यवहार निर्धारित नहीं करता। नीचे दिया गया उसका परिणाम केवल परीक्षण किए गए बिल्ड के लिए एक अवलोकन है।

कार्यप्रणाली

मुख्य मीट्रिक चार vCPU के पूर्ण लोड पर Games प्रोफ़ाइल में आवधिक कार्य के शुभारंभ की p99 विलंबता है। एक स्वतंत्र रन 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 event या buffer नहीं था। अवसंरचना संबंधी पायलट परिणामों में शामिल नहीं किए गए।

परिणाम

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 पंजीकरण के बिना लौटी, इसलिए इसे चल रहे MMCSS से प्रश्न का परिणाम नहीं, बल्कि API fallback के रूप में दर्शाया गया है। इस बिल्ड में अक्षम स्थिति की पुष्टि सेवा और पंजीकरण से अलग-अलग हुई, लेकिन इसे स्वचालित रूप से Windows के अन्य संस्करणों पर लागू नहीं किया जा सकता।

नई स्थिति का विश्वसनीय अनुप्रयोग पुनःआरंभ के बाद देखा गया। Registry में परिवर्तन ने पहले से खुले MMCSS handle या वर्तमान बूट में नई प्रक्रिया की स्थिति नहीं बदली। सेवा को रोकने और शुरू करने का असफल प्रयास अनुप्रयोग का समर्थित तरीका नहीं माना जाता।

सिंथेटिक विलंबता की p99

धनात्मक अंतर का अर्थ है 20 के सापेक्ष अधिक, यानी बदतर, p99 विलंबता।

`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 Windows के बूट के बाद MMCSS की देखी गई स्थिति बदलता है।
0 प्रभावी स्थिति 0 नहीं बनाता, बल्कि 20 तक सामान्यीकृत होता है।
10 और 20 थ्रेड के पंजीकरण की अनुमति देते हैं और इस परीक्षण में उसकी प्राथमिकता का समान संक्रमण देते हैं।
चुनी गई p99 मीट्रिक पर 10 का 20 पर व्यावहारिक रूप से महत्वपूर्ण लाभ स्थापित नहीं हुआ।
100 MMCSS को अक्षम कर देता है; परीक्षण किए गए बिल्ड में वही स्थिति अनुपस्थित value पर भी देखी गई।
अक्षम MMCSS पर परीक्षण थ्रेड को प्राथमिकता बढ़ोतरी नहीं मिली, और सिंथेटिक p99 विलंबता दोनों श्रृंखलाओं में बिगड़ी।

क्या पुष्ट नहीं हुआ

यह कि 10 और 20 सभी MMCSS workload के लिए समतुल्य हैं।
यह कि 10 FPS बढ़ाता है, input latency घटाता है या ऑडियो सुधारता है।
यह कि 100 अनिवार्य रूप से audio glitches, डीसिंक या किसी विशिष्ट गेम में समस्याएँ पैदा करता है।
यह कि अनुपस्थित value का अवलोकन Windows के किसी अन्य बिल्ड पर दोहराता है।
यह कि प्राप्त मिलीसेकंड भौतिक end-to-end latency हैं।
यह कि वर्चुअल मशीन का परिणाम भौतिक PC पर लागू होता है।

सीमाएँ

अध्ययन एक 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 श्रृंखलाएँ, थ्रेड प्राथमिकता की जाँच, ऑडियो और गेम के लिए सीमाएँ, तथा पुष्ट स्थिति बहाली जोड़ी गई।