Перейти к содержимому

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 یا حقیقی آواز کی خرابی کا ثبوت بھی نہیں۔

عملی سیٹنگ کا صفحہ: «پس منظر کے کاموں کے لیے CPU ریزرو»۔

تحقیق نے تین الگ الگ دعوے جانچے:

  1. کیا 0، 10، 20، 100 اور غیر موجود قیمت بوٹ کے بعد MMCSS کی اصل حالت تبدیل کرتے ہیں۔
  2. کیا 10 مکمل CPU لوڈ کے تحت مصنوعی MMCSS workload کی p99 تاخیر میں 20 پر عملی طور پر اہم برتری دیتا ہے۔
  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 کی ایک build سے متعلق ہے۔

build کی تصدیق Microsoft Support کے اپ ڈیٹ صفحہ KB5121003 سے ہوتی ہے۔

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 کے رویے کی وضاحت نہیں کرتی۔ اس کا نتیجہ نیچے صرف جانچی گئی build کے لیے ایک مشاہدہ ہے۔

بنیادی پیمائش Games پروفائل میں متواتر کام کے آغاز کی p99 تاخیر ہے، چاروں vCPU کے مکمل لوڈ کے تحت۔ ایک آزاد رن Windows کے الگ بوٹ کے بعد ایک حالت کے مساوی تھا۔ ہر رن کے اندر 2500 ادوار چلائے گئے، مگر انہیں آزاد تکرار نہیں سمجھا گیا۔

ہر حالت کے لیے 10 بوٹس کی دو سیریز کی گئیں۔ حالتوں کی ترتیب متوازن رکھی گئی، آؤٹ لائرز حذف نہیں کیے گئے۔ عملی طور پر اہم حد پہلے سے 1.784 ms مقرر تھی۔ 20 حالت کے فرق کے لیے paired bootstrap 95% CI استعمال کیا گیا۔

سیریز الگ الگ دکھائی گئی ہیں: دوسری سیریز میں ایک اضافی validation-only ETW سیشن چل رہا تھا جو پہلی میں نہیں تھا۔ یہ بنیادی پیمائش کا ذریعہ نہیں تھا، مگر دوسرا بلاک زیادہ شور والا نکلا، اس لیے 20 رنز کی مشترکہ تعداد ڈیٹا کی غیر یکسانی چھپا سکتی تھی۔

میکانزم کی الگ جانچ میں 10، 20، 100 اور غیر موجود قیمت کے لیے چار چار بوٹس شامل تھے۔ ایک ہی تھریڈ کو MMCSS رجسٹریشن کی کوشش سے پہلے، اس کے بعد اور cleanup کے بعد ماپا گیا۔ رجسٹریشن کا نتیجہ، Win32 thread priority اور ETW کے مطابق شیڈولر کی اصل ترجیح جانچی گئی۔ تمام 16 بنیادی رنز قبول کیے گئے؛ اس سیریز میں کوئی ETW event یا buffer ضائع نہیں ہوا۔ انفراسٹرکچر پائلٹس نتائج میں شامل نہیں کیے گئے۔

درج شدہ بوٹ کے بعد مشاہدہ شدہ حالت نتیجہ
غیر موجود MMCSS بند، رجسٹریشن نہیں ہوئی، API نے 100 واپس کیا اس build کے لیے الگ مشاہدہ
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 سے استفسار کے نتیجے کے طور پر۔ اس build میں غیر فعال حالت کی تصدیق سروس اور رجسٹریشن سے الگ ہوئی، مگر اسے خود بخود دیگر Windows ورژنز پر منتقل نہیں کیا جا سکتا۔

نئی حالت کا قابلِ اعتماد اطلاق دوبارہ بوٹ کے بعد مشاہدہ ہوا۔ Registry کی تبدیلی نے موجودہ بوٹ میں پہلے سے کھلے MMCSS handle یا نئے پروسیس کی حالت تبدیل نہیں کی۔ سروس کو روکنے اور چلانے کی ناکام کوشش کو اطلاق کا معاون طریقہ نہیں سمجھا جاتا۔

مثبت فرق کا مطلب 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 کی حالت ایک تھریڈ کی 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 اور دیگر resource accounting rules کا الگ حصہ الگ نہیں کیا گیا۔

100 اور غیر موجود قیمت سروس کی حالت، رجسٹریشن کے نتیجے اور تھریڈ کی ترجیح میں مماثل تھے۔ یہ تمام داخلی اور صارفی منظرناموں میں ان کی مکمل مساوات کا ثبوت نہیں۔

  • SystemResponsiveness Windows بوٹ کے بعد MMCSS کی مشاہدہ شدہ حالت تبدیل کرتا ہے۔
  • 0 مؤثر حالت 0 پیدا نہیں کرتا، بلکہ 20 تک نارملائز ہوتا ہے۔
  • 10 اور 20 تھریڈ کی رجسٹریشن کی اجازت دیتے ہیں اور اس ٹیسٹ میں اس کی ترجیح کی ایک جیسی منتقلی دیتے ہیں۔
  • منتخب p99 پیمائش میں 10 کی 20 پر عملی طور پر اہم برتری ثابت نہیں ہوئی۔
  • 100 MMCSS کو غیر فعال کرتا ہے؛ جانچی گئی build میں وہی حالت غیر موجود value پر بھی مشاہدہ ہوئی۔
  • غیر فعال MMCSS پر ٹیسٹ تھریڈ کو ترجیح میں اضافہ نہ ملا، اور مصنوعی p99 تاخیر دونوں سیریز میں بگڑ گئی۔
  • یہ کہ 10 اور 20 تمام MMCSS workload کے لیے مساوی ہیں۔
  • یہ کہ 10 FPS بڑھاتا ہے، input latency کم کرتا ہے یا آواز بہتر بناتا ہے۔
  • یہ کہ 100 لازمی طور پر audio glitches، بے ترتیبی یا کسی مخصوص گیم میں مسائل پیدا کرتا ہے۔
  • یہ کہ غیر موجود value کا مشاہدہ کسی دوسری Windows build پر بھی دہرایا جاتا ہے۔
  • یہ کہ حاصل شدہ ملی سیکنڈز حقیقی end-to-end latency ہیں۔
  • یہ کہ ورچوئل مشین کا نتیجہ کسی فزیکل PC پر منتقل ہوتا ہے۔

تحقیق ایک VMware VM اور Windows کی ایک build پر کی گئی۔ مصنوعی پروفائل Games CPU کے لیے قابلِ کنٹرول مقابلہ پیدا کرتا ہے، مگر گیم انجن، آڈیو ڈرائیور، حقیقی input pipeline یا display scanout کی نقل نہیں کرتا۔

دوسری سیریز میں اضافی ETW سیشن صرف validation کے لیے استعمال ہوا، مگر یہ مجموعی شور کی سطح بدل سکتا تھا۔ اس لیے دو سیریز کو ایک تخمینے میں شامل نہیں کیا گیا۔ میکانزم کی جانچ ترجیحی اضافے کے ضیاع کو دکھاتی ہے، مگر MMCSS quota اور accounting policy کے ممکنہ حصے کو الگ نہیں کرتی۔

فزیکل آڈیو ٹیسٹ، FPS، frametime، click-to-photon اور input latency نہیں ماپے گئے۔ کسی دوسری مشین یا build پر آزاد تکرار ابھی نہیں ہے۔

0 کو «صفر ریزرو» مقرر کرنے کا طریقہ نہ سمجھیں: Windows اسے 20 بنا دیتا ہے۔ 10 کو ثابت شدہ بہترین عالمگیر قیمت نہ سمجھیں: اس VM میں 20 پر برتری ثابت نہیں ہوئی۔

100 استعمال نہ کریں اور «پابندیوں کو غیر فعال کرنے» کے لیے value حذف نہ کریں۔ جانچے گئے ماحول میں اس نے MMCSS غیر فعال کیا، تھریڈ کو ترجیحی اضافے سے محروم کیا اور مصنوعی p99 تاخیر کو نمایاں طور پر بگاڑا۔ الگ فزیکل ٹیسٹ کے بغیر اس نتیجے کو FPS یا آواز کی درست پیش گوئی میں تبدیل نہیں کیا جا سکتا۔

عام سسٹم کے لیے محفوظ نتیجہ Windows کی طے شدہ حالت برقرار رکھنے تک محدود ہے۔ تبدیلی صرف اسی صورت میں جائز ہے جب صارف کی پیمائش پہلے سے منتخب ہو، بار بار paired پیمائشیں کی گئی ہوں اور واپسی کی تصدیق ہو۔

مختصر صارفی سفارش اور رجسٹری کی درست حالت صفحہ «SystemResponsiveness» پر شائع ہے۔

ہر تجرباتی مرحلے کے بعد VM محفوظ ابتدائی حالت میں واپس لائی گئی۔ کنٹرول بوٹ نے Registry value 20، چلتے MMCSS، فعال ٹریسنگ کی عدم موجودگی اور ٹیسٹ پروسیسز کے اختتام کی تصدیق کی۔ جانچ کے بعد دوبارہ واپسی کی گئی، VM بند چھوڑی گئی۔

عوامی ماخذ اور عبارات جانچی گئیں: 2026-08-25۔

تحقیق اور استعمال شدہ ٹولز BoosterX کے ڈویلپر کی ملکیت ہیں، اس لیے ڈویلپر کا نتائج میں براہِ راست مفاد ہے۔ طریقہ کار اور اطلاق کی حدود اوپر بیان کی گئی ہیں، اور نتائج کو کھلے ڈیٹا اور درج عوامی ماخذ سے جانچا جا سکتا ہے۔ مصنوع میں پیرامیٹر کی موجودگی کو ثبوت کے طور پر استعمال نہیں کیا گیا؛ 10 کا غیر متعین نتیجہ اور MMCSS غیر فعال کرنے کا منفی نتیجہ بغیر چھانٹ کے محفوظ رکھے گئے۔

BoosterX Wiki ایک آزاد اشاعت ہے اور Microsoft Corporation سے منسلک، مجاز، سپانسر شدہ یا منظور شدہ نہیں۔

  • 2026-09-20: مفادات کے تصادم کا ڈس کلیمر مکمل عبارت تک مضبوط کیا گیا، جس میں تحقیق اور ٹولز کی ملکیت شامل ہے۔
  • 2026-08-25: پہلی اشاعت؛ دو الگ p99 سیریز، تھریڈ کی ترجیح کی جانچ، آڈیو اور گیمز کے لیے حدود، اور تصدیق شدہ حالت کی بحالی شامل کی گئی۔