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 لزمن استجابة حمل جدولة اصطناعي بنحو 11-12 ms مقارنةً بـ 20. هذه النتيجة لا تعني أن Windows أصبحت أبطأ بنسبة 60% بشكل عام، ولا تُثبت تدهور FPS أو input latency أو الصوت الفعلي.

الإعدادات المرتبطة في BoosterX

صفحة الإعداد العملية: «احتياطي CPU للمهام الخلفية».

الادعاء القابل للتحقق

فحص البحث ثلاثة ادعاءات منفصلة:

1. هل تغيّر 0، 10، 20، 100 والقيمة الغائبة الحالة الفعلية لـ MMCSS بعد الإقلاع.
2. هل تمنح 10 تفوقًا ذا دلالة عملية على 20 في p99 لزمن استجابة حمل 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 بأنه آلية تتيح لحمل الوسائط المتعددة الحساس للوقت الحصول على وصول ذي أولوية إلى 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 الغائبة. نتيجتها أدناه ملاحظة تخص البناء المُختبَر فقط.

المنهجية

المقياس الأساسي هو p99 لزمن استجابة بدء عمل دوري في ملف التعريف Games عند تحميل كامل لأربع vCPU. جرى تشغيل مستقل واحد لكل حالة بعد إقلاع منفصل لـ Windows. داخل كل تشغيل نُفِّذت 2500 دورة، لكنها لم تُعتبر تكرارات مستقلة.

لكل حالة أُجريت سلسلتان من 10 عمليات إقلاع. وُوزِن ترتيب الحالات، ولم تُحذف القيم الشاذة. حُدِّدت عتبة الدلالة العملية مسبقًا عند 1.784 ms. وللفرق مع حالة 20 استُخدم bootstrap مزدوج بنسبة ثقة 95% CI.

عُرضت السلسلتان منفصلتين: في السلسلة الثانية عملت جلسة 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. عند القيمة الغائبة أُعيد الرقم 100 دون تسجيل صالح لـ MMCSS، لذا ذُكر كـ API fallback وليس كنتيجة استعلام على MMCSS عامل. أُكِّدت الحالة المعطَّلة في هذا البناء بشكل منفصل عبر الخدمة والتسجيل، لكن لا يمكن نقلها تلقائيًا إلى إصدارات Windows أخرى.

لوحظ التطبيق الموثوق للحالة الجديدة بعد إعادة التشغيل. لم يغيّر تعديل Registry حالة مقبض MMCSS المفتوح مسبقًا أو عملية جديدة في الإقلاع الحالي. ولا تُعتبر محاولة إيقاف الخدمة وتشغيلها الفاشلة طريقة تطبيق مدعومة.

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؛ وفي البناء المُختبَر لوحظت الحالة نفسها عند القيمة الغائبة.
• عند MMCSS المعطَّل لم يحصل خيط الاختبار على رفع الأولوية، وتدهور p99 الاصطناعي لزمن الاستجابة في كلتا السلسلتين.

ما لم يتم تأكيده

• أن 10 و20 متكافئتان لجميع أحمال MMCSS.
• أن 10 ترفع FPS أو تقلل input latency أو تحسّن الصوت.
• أن 100 تسبب بالضرورة audio glitches أو عدم تزامن أو مشكلات في لعبة معينة.
• أن ملاحظة القيمة الغائبة تتكرر على بناء Windows آخر.
• أن المللي ثانية الناتجة هي زمن استجابة فيزيائي من الطرف إلى الطرف.
• أن نتيجة الجهاز الافتراضي تنتقل إلى حاسوب فعلي.

القيود

أُجري البحث على 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 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، وفحص أولوية الخيط، وحدود الصوت والألعاب، إضافةً إلى استعادة الحالة المؤكَّدة.