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

BoosterX: Windows-এর ব্যাকগ্রাউন্ড ও CS2-এর FPS

На этой странице

চারটি পর্যায়ের তুলনা, একই PC-তে। BoosterX-এর অপ্টিমাইজেশনগুলো ধারাবাহিকভাবে প্রয়োগ করার পর Windows-এর ব্যাকগ্রাউন্ড কার্যকলাপ কমেছে, আর নির্বাচিত CS2 বেঞ্চমার্কে গড় FPS প্রস্তুত করা Clean সিস্টেমের তুলনায় 2,23–2,96% বেড়েছে। Advanced Advanced-এ গড় FPS ছিল সর্বোচ্চ, আর Expert Hardcore-এ P1 ছিল সর্বোচ্চ এবং রেকর্ড করা নিষ্ক্রিয় অবস্থায় কার্যকলাপ ছিল সর্বনিম্ন।

পরিমাপগুলো BoosterX-এর ডেভেলপার করেছেন। ফলাফলটি নির্দিষ্ট পরীক্ষাব্যবস্থায় চালানো একটি সিরিজের ক্ষেত্রে প্রযোজ্য। গণনায় আটটি FPS রান এবং WPR-এর সম্পূর্ণ পাঁচ মিনিটের উইন্ডো অন্তর্ভুক্ত করা হয়েছে।

WPR ফলাফল · CS2 ফলাফল · পদ্ধতি · মূল ডেটা ডাউনলোড করুন

উদ্দেশ্য: Clean → Safe Advanced → Advanced Advanced → Expert Hardcore-এ ধারাবাহিকভাবে যাওয়ার সময় নির্দিষ্ট CS2 পরিস্থিতিতে Windows-এর ব্যাকগ্রাউন্ড কার্যকলাপ ও পারফরম্যান্স কীভাবে বদলায়, তা পরীক্ষা করা।

WPR এবং CapFrameX ভিন্ন প্রশ্নের উত্তর দেয়। WPR সাইন-ইন করার পর এবং নিষ্ক্রিয় অবস্থায় সিস্টেমের কার্যকলাপ দেখায়। CapFrameX গেমের লোডের সময় ফ্রেমের মধ্যবর্তী ব্যবধান মাপে। ব্যাকগ্রাউন্ড CPU কয়েক গুণ কমলেই FPS একই অনুপাতে বাড়বে—এমন নয়।

পরীক্ষাব্যবস্থা ও প্রস্তুতি

Заголовок раздела « পরীক্ষাব্যবস্থা ও প্রস্তুতি»
প্যারামিটার পরীক্ষার শর্ত
পরিমাপের তারিখ 24 অক্টোবর 2026 বছর
CPU AMD Ryzen 7 7800X3D, 8 কোর / 16 থ্রেড
GPU NVIDIA GeForce RTX 5070, ড্রাইভার 617.42
RAM 32 GB, 2 × 16 GB DDR5-6000
মাদারবোর্ড / BIOS ASRock B850 Riptide WiFi / 4.20
Windows Windows 11 Pro 26H2, বিল্ড 26300.9711
BoosterX 2.4.2.4, Debug বিল্ড; ব্যবহৃত বাইনারি ফাইলের হ্যাশ সংরক্ষিত হয়নি
CapFrameX 1.8.6.2
CS2 CS2 FPS BENCHMARK DUST2, Workshop ID 3240880604
গ্রাফিক্স 1280×960, Low প্রিসেট, FidelityFX বন্ধ, Reflex চালু, fps_max 0
অন্যান্য সেটিংস ReBAR, Game Mode এবং HAGS চালু; CapFrameX প্রদর্শন মোড Fullscreen Optimized or Borderless হিসেবে শনাক্ত করেছে
পাওয়ার Clean, Safe এবং Advanced: «Balanced»; Expert Hardcore: PowerX v2.1

প্রস্তুতি: Windows-এর পরিষ্কার ইনস্টলেশন, সব আপডেট, Steam, Spotify এবং AMD চিপসেট ড্রাইভার। CS2 ফাইল অন্য একটি ড্রাইভ থেকে স্থানান্তর করা হয়েছে। DDU দিয়ে ভিডিও ড্রাইভার সরিয়ে, NVIDIA-এর কম উপাদানসহ কাস্টম ইনস্টলেশন টুল ব্যবহার করে নতুন করে ইনস্টল করা হয়েছে। উপাদানগুলোর সঠিক তালিকা এবং চিপসেট ড্রাইভারের সংস্করণ আলাদাভাবে সংরক্ষিত হয়নি। বেসলাইন পরিমাপের আগে অন্য কোনো ম্যানুয়াল পরিবর্তন করা হয়নি।

অতএব, এখানে Clean বলতে BoosterX প্রয়োগের আগের প্রস্তুত করা সিস্টেমকে বোঝায়, যেখানে অ্যাপ্লিকেশন ও ড্রাইভার আগে থেকেই ইনস্টল করা ছিল। এটি ইনস্টলেশনের প্রথম স্ক্রিনের পরপরই থাকা Windows নয়। Clean-এর ETL-এ OneDrive এবং Edge উপাদানগুলোর কার্যকলাপও রয়েছে।

সেন্সর ডেটা অনুযায়ী, FPS রানগুলোর সময় CPU Max-এর গড় ফ্রিকোয়েন্সি ছিল প্রায় 5035–5043 MHz, আর GPU-এর প্রায় 2927–2930 MHz। ফ্রিকোয়েন্সি পরিবর্তিত হয়েছে: CPU/GPU clocks স্থির রেখে সিরিজটি চালানো হয়নি। CPU Max প্রতিটি কোরের কার্যকর ফ্রিকোয়েন্সির পরিমাপ নয়। PBO এবং Curve Optimizer-এর সেটিংস নথিভুক্ত করা হয়নি।

একই Windows ইনস্টলেশনে চারটি অবস্থা ধারাবাহিকভাবে প্রয়োগ করা হয়েছে। প্রতিটি পর্যায়ে প্রথমে WPR চক্র, তারপর FPS পরীক্ষা চালানো হয়েছে। পর্যায়গুলোর মধ্যে Clean ইমেজে ফেরত যাওয়া হয়নি; পরিবর্তনগুলো জমা হয়েছে। সংরক্ষিত ফাইলসমষ্টিতে ETL ছাড়া Expert Hardcore-এর একটি অসম্পূর্ণ WPR প্রচেষ্টা রয়েছে। সারাংশে পরবর্তী সম্পূর্ণ রেকর্ডিংটি অন্তর্ভুক্ত করা হয়েছে। Expert Hardcore-এর একটি FPS রান এই সম্পূর্ণ WPR রেকর্ডিংয়ের আগে, আর দ্বিতীয়টি পরে চালানো হয়েছে।

WPR: সিস্টেমে সাইন-ইন করার সময় রেকর্ডিং শুরু হওয়ার পর পাঁচ মিনিট, স্থিতিশীল হওয়ার জন্য পাঁচ মিনিট, তারপর পাঁচ মিনিট নিষ্ক্রিয় অবস্থা। CPU, ডিস্ক, ফাইল এবং নেটওয়ার্ক কার্যকলাপের হালকা প্রোফাইল রেকর্ড করা হয়েছে। প্রতিটি পর্যায়ের শুরু ও শেষের মার্কারের মধ্যবর্তী ETL থেকে সরাসরি হিসাব করা হয়েছে। প্রতিটি উইন্ডোর সময়কাল 300 সেকেন্ড থেকে 0,02 সেকেন্ডেরও কম ব্যবধানে আলাদা। আটটি ETL-এর সবকটির হেডারে ইভেন্ট ও বাফার হারানোর সংখ্যা শূন্য দেখানো হয়েছে।

প্রথম পর্যায়টি Windows বুট হওয়ার প্রায় 15–23তম সেকেন্ডে শুরু হয়েছে। এই পরীক্ষায় OS বুটের সময় মাপা হয়নি। ETL থেকে চূড়ান্ত মেট্রিকগুলো পুনরায় হিসাব করা হয়েছে।

CS2: প্রতিটি পর্যায়ে আনুমানিক 105 সেকেন্ডের দুটি করে রান। স্বয়ংক্রিয় ম্যাপ স্ক্রিপ্ট ব্যবহার করা হয়েছে। প্রায় একই রেফারেন্স পয়েন্টে হটকি দিয়ে CapFrameX রেকর্ডিং ম্যানুয়ালি চালু করা হয়েছে। ফ্রেম-টু-ফ্রেম শুরুর সিঙ্ক্রোনাইজেশন করা হয়নি। প্রক্রিয়ার নাম infinst.exe ভুল থাকা দুটি ফাইলও CS2 পরীক্ষার অংশ। আর্কাইভে মূল নাম ও JSON-এর বিষয়বস্তু সংরক্ষিত আছে।

CS2-এর সঠিক build, রেকর্ডিংয়ের সময় ম্যাপের কনটেন্ট সংস্করণ, MSAA-এর পৃথক মান এবং প্রাথমিক ওয়ার্ম-আপের সময়কাল নথিভুক্ত করা হয়নি। Workshop-এ থাকা ম্যাপের বর্তমান সংস্করণ ব্যবহৃত সংস্করণ থেকে আলাদা হতে পারে। তুলনাটি এই ম্যাপের ক্ষেত্রে প্রযোজ্য, প্রতিযোগিতামূলক ম্যাচে FPS-এর ক্ষেত্রে নয়: ম্যাপের নির্মাতারা স্থানীয় সিমুলেশন ও সার্ভারে খেলার মধ্যে পার্থক্য আলাদাভাবে উল্লেখ করেছেন।

WPR: Windows-এর ব্যাকগ্রাউন্ড কার্যকলাপ

Заголовок раздела « WPR: Windows-এর ব্যাকগ্রাউন্ড কার্যকলাপ»
WPR · Clean-এর তুলনায় Δ: পার্থক্য ও শতাংশ · ↔ ↕
সূচকCleanSafe AdvancedAdvanced AdvancedExpert Hardcore
সাইন ইন করার পর: প্রথম 5 মিনিটের রেকর্ডিং
CPU-এর গড় ব্যবহার, %১.৪৮৮ভিত্তি০.৪১১Δ −১.০৭৭ পয়েন্ট−৭২.৩৭%০.৩১৪Δ −১.১৭৪ পয়েন্ট−৭৮.৯১%০.২৮৩Δ −১.২০৫ পয়েন্ট−৮০.৯৯%
প্রায় 1 সেকেন্ডের ব্যবধানে CPU-এর সর্বোচ্চ ব্যবহার, %৩০.৬০ভিত্তি১৪.৩০Δ −১৬.৩০ পয়েন্ট−৫৩.২৭%১১.৩৬Δ −১৯.২৪ পয়েন্ট−৬২.৮৯%৬.৪৪Δ −২৪.১৬ পয়েন্ট−৭৮.৯৫%
CPU সময়ের অনুমান, কোর·সেকেন্ড৭১.৪২ভিত্তি১৯.৭৩Δ −৫১.৬৮−৭২.৩৭%১৫.০৬Δ −৫৬.৩৫−৭৮.৯১%১৩.৫৮Δ −৫৭.৮৪−৮০.৯৮%
প্রতি সেকেন্ডে কনটেক্সট সুইচ৫,৭৮১.৮ভিত্তি১,৩৩০.৬Δ −৪,৪৫১.২−৭৬.৯৯%১,০০৬.৩Δ −৪,৭৭৫.৪−৮২.৫৯%৭৬৩.৩Δ −৫,০১৮.৫−৮৬.৮০%
মোট কনটেক্সট সুইচ১৭,৩৪,৫২৩ভিত্তি৩,৯৯,১৯৮Δ −১৩,৩৫,৩২৫−৭৬.৯৯%৩,০১,৯০০Δ −১৪,৩২,৬২৩−৮২.৫৯%২,২৯,০০০Δ −১৫,০৫,৫২৩−৮৬.৮০%
প্রতি সেকেন্ডে Ready অবস্থায় থ্রেড স্থানান্তর৩,৬৯২.২ভিত্তি৮১৭.৯Δ −২,৮৭৪.২−৭৭.৮৫%৬১৪.৭Δ −৩,০৭৭.৫−৮৩.৩৫%৪৫৫.৭Δ −৩,২৩৬.৫−৮৭.৬৬%
সময়সীমার শেষে প্রসেস১৪৮ভিত্তি৯৬Δ −৫২−৩৫.১৪%৯২Δ −৫৬−৩৭.৮৪%৬৭Δ −৮১−৫৪.৭৩%
সময়সীমায় প্রসেস চালু১১৩ভিত্তি২৭Δ −৮৬−৭৬.১১%১৮Δ −৯৫−৮৪.০৭%১৬Δ −৯৭−৮৫.৮৪%
সময়সীমার শেষে থ্রেড২,৫৬৬ভিত্তি১,৭১৮Δ −৮৪৮−৩৩.০৫%১,৬৪৩Δ −৯২৩−৩৫.৯৭%১,৩৪৯Δ −১,২১৭−৪৭.৪৩%
সময়সীমায় থ্রেড চালু২,৮৩৩ভিত্তি১,০৩০Δ −১,৮০৩−৬৩.৬৪%৮৩২Δ −২,০০১−৭০.৬৩%৬৮৩Δ −২,১৫০−৭৫.৮৯%
প্রসেসের ওয়ার্কিং সেটের যোগফল¹, MiB৫,০৫৪.৫ভিত্তি৩,২৮৩.৬Δ −১,৭৭০.৯−৩৫.০৪%২,৯৫৪.৫Δ −২,০৯৯.৯−৪১.৫৫%২,২৩৪.৪Δ −২,৮২০.০−৫৫.৭৯%
প্রসেসের commit-এর যোগফল¹, MiB২,৫৮৯.৯ভিত্তি১,৬৮৫.১Δ −৯০৪.৮−৩৪.৯৩%১,৫৮৬.২Δ −১,০০৩.৭−৩৮.৭৬%১,১৯৫.৬Δ −১,৩৯৪.৩−৫৩.৮৪%
প্রসেস হ্যান্ডেল¹৬৬,১৮৭ভিত্তি৪৩,২৪৭Δ −২২,৯৪০−৩৪.৬৬%৪০,৫২০Δ −২৫,৬৬৭−৩৮.৭৮%৩০,৯৮৭Δ −৩৫,২০০−৫৩.১৮%
DPC / সেকেন্ড৯৮১.৭ভিত্তি৩৪৭.৪Δ −৬৩৪.৩−৬৪.৬১%৩০৬.৪Δ −৬৭৫.৪−৬৮.৭৯%২০৪.২Δ −৭৭৭.৫−৭৯.২০%
হার্ডওয়্যার ইন্টারাপ্ট (ISR) / সেকেন্ড৪২০.১ভিত্তি১২০.৪Δ −২৯৯.৭−৭১.৩৪%১০২.৭Δ −৩১৭.৪−৭৫.৫৬%৯২.৩Δ −৩২৭.৮−৭৮.০৩%
সময়সীমায় Hard fault²১৬,২৫১ভিত্তি৯,৬৬১Δ −৬,৫৯০−৪০.৫৫%৬,০৪৯Δ −১০,২০২−৬২.৭৮%৫,২৭১Δ −১০,৯৮০−৬৭.৫৭%
ডিস্ক থেকে পড়া, MiB৯২০.৩৬ভিত্তি২৯৫.৬৭Δ −৬২৪.৬৯−৬৭.৮৭%২৩৭.০০Δ −৬৮৩.৩৬−৭৪.২৫%২১৮.৯৬Δ −৭০১.৪০−৭৬.২১%
ডিস্কে লেখা, MiB৭৫৮.৪১ভিত্তি১২৩.৪৩Δ −৬৩৪.৯৮−৮৩.৭৩%৮৯.১৩Δ −৬৬৯.২৮−৮৮.২৫%৬৬.২৭Δ −৬৯২.১৩−৯১.২৬%
এর মধ্যে WPR³ ফাইল লেখা, MiB৫৯১.৭৬ভিত্তি৮৫.০০Δ −৫০৬.৭৬−৮৫.৬৪%৬২.০০Δ −৫২৯.৭৬−৮৯.৫২%৪২.০০Δ −৫৪৯.৭৬−৯২.৯০%
ডিস্ক থেকে পড়ার অপারেশন২৯,১২৪ভিত্তি১৬,৭১৮Δ −১২,৪০৬−৪২.৬০%১৩,২৩৪Δ −১৫,৮৯০−৫৪.৫৬%১২,৩৯১Δ −১৬,৭৩৩−৫৭.৪৫%
ডিস্কে লেখার অপারেশন১৩,২৯৮ভিত্তি৩,১১৮Δ −১০,১৮০−৭৬.৫৫%২,১৫৭Δ −১১,১৪১−৮৩.৭৮%১,৫৮৮Δ −১১,৭১০−৮৮.০৬%
সময়সীমার দৈর্ঘ্য, সেকেন্ড৩০০.০০০৩০০.০১৮৩০০.০০৩৩০০.০১৫
নিষ্ক্রিয় সময়: চক্রের শেষ 5 মিনিট
CPU-এর গড় ব্যবহার, %১.২৩৮ভিত্তি১.৬৯৪Δ +০.৪৫৬ পয়েন্ট+৩৬.৮৬%০.৩৩৭Δ −০.৯০১ পয়েন্ট−৭২.৭৭%০.১৮৩Δ −১.০৫৫ পয়েন্ট−৮৫.২৫%
প্রায় 1 সেকেন্ডের ব্যবধানে CPU-এর সর্বোচ্চ ব্যবহার, %১২.১৭ভিত্তি১৭.৭৪Δ +৫.৫৭ পয়েন্ট+৪৫.৭৯%৬.৪৭Δ −৫.৭০ পয়েন্ট−৪৬.৮৬%৬.২৫Δ −৫.৯২ পয়েন্ট−৪৮.৬৪%
CPU সময়ের অনুমান, কোর·সেকেন্ড৫৯.৪১ভিত্তি৮১.৩১Δ +২১.৯০+৩৬.৮৬%১৬.১৮Δ −৪৩.২৩−৭২.৭৭%৮.৭৬Δ −৫০.৬৪−৮৫.২৫%
প্রতি সেকেন্ডে কনটেক্সট সুইচ১,৯৪৪.৯ভিত্তি২,০৬১.৬Δ +১১৬.৭+৬.০০%৮০৬.৯Δ −১,১৩৮.০−৫৮.৫১%৩৩৬.৫Δ −১,৬০৮.৪−৮২.৭০%
মোট কনটেক্সট সুইচ৫,৮৩,৪৪০ভিত্তি৬,১৮,৪৭৭Δ +৩৫,০৩৭+৬.০১%২,৪২,০৭১Δ −৩,৪১,৩৬৯−৫৮.৫১%১,০০,৯৬৭Δ −৪,৮২,৪৭৩−৮২.৬৯%
প্রতি সেকেন্ডে Ready অবস্থায় থ্রেড স্থানান্তর১,২০৮.০ভিত্তি১,২৭২.০Δ +৬৪.০+৫.৩০%৫২২.৯Δ −৬৮৫.১−৫৬.৭২%২০০.৩Δ −১,০০৭.৭−৮৩.৪২%
সময়সীমার শেষে প্রসেস১৫৩ভিত্তি১০১Δ −৫২−৩৩.৯৯%৯০Δ −৬৩−৪১.১৮%৬৪Δ −৮৯−৫৮.১৭%
সময়সীমায় প্রসেস চালু১৯ভিত্তি১৬৮Δ +১৪৯+৭৮৪.২১%৬Δ −১৩−৬৮.৪২%৫Δ −১৪−৭৩.৬৮%
সময়সীমার শেষে থ্রেড২,৩৮৮ভিত্তি১,৬৭৮Δ −৭১০−২৯.৭৩%১,৪১২Δ −৯৭৬−৪০.৮৭%১,১৮৯Δ −১,১৯৯−৫০.২১%
সময়সীমায় থ্রেড চালু১,২০০ভিত্তি২,৩২১Δ +১,১২১+৯৩.৪২%৫৪১Δ −৬৫৯−৫৪.৯২%৩৩৩Δ −৮৬৭−৭২.২৫%
প্রসেসের ওয়ার্কিং সেটের যোগফল¹, MiB৫,১৫০.৬ভিত্তি৩,৪৭৭.৭Δ −১,৬৭২.৯−৩২.৪৮%২,৮৯০.৬Δ −২,২৬০.০−৪৩.৮৮%২,২০২.৮Δ −২,৯৪৭.৮−৫৭.২৩%
প্রসেসের commit-এর যোগফল¹, MiB২,৮৪৭.৪ভিত্তি১,৭৯৬.৩Δ −১,০৫১.১−৩৬.৯১%১,৫৮৭.৯Δ −১,২৫৯.৫−৪৪.২৩%১,২২৩.৯Δ −১,৬২৩.৫−৫৭.০২%
প্রসেস হ্যান্ডেল¹৬৮,৬২৮ভিত্তি৪৫,৮৬৭Δ −২২,৭৬১−৩৩.১৭%৩৯,৮৮৮Δ −২৮,৭৪০−৪১.৮৮%৩০,৫৯৭Δ −৩৮,০৩১−৫৫.৪২%
DPC / সেকেন্ড১,২১০.৫ভিত্তি২৭৭.৫Δ −৯৩৩.০−৭৭.০৮%২১৬.৭Δ −৯৯৩.৭−৮২.০৯%১০৮.৮Δ −১,১০১.৭−৯১.০১%
হার্ডওয়্যার ইন্টারাপ্ট (ISR) / সেকেন্ড৯২২.১ভিত্তি৮৬.৫Δ −৮৩৫.৬−৯০.৬২%৬৪.৩Δ −৮৫৭.৮−৯৩.০৩%৪৬.৮Δ −৮৭৫.৩−৯৪.৯৩%
সময়সীমায় Hard fault²৬৩৬ভিত্তি৫,২৫৮Δ +৪,৬২২+৭২৬.৭৩%১,০৪০Δ +৪০৪+৬৩.৫২%১,২০৩Δ +৫৬৭+৮৯.১৫%
ডিস্ক থেকে পড়া, MiB১২.৯০ভিত্তি১০৫.৩২Δ +৯২.৪২+৭১৬.২৮%৮১.৫০Δ +৬৮.৬০+৫৩১.৬৪%৯.৮৩Δ −৩.০৭−২৩.৭৮%
ডিস্কে লেখা, MiB২১৪.৫৭ভিত্তি৩১৭.৮৪Δ +১০৩.২৭+৪৮.১৩%৮৬.৯৭Δ −১২৭.৬০−৫৯.৪৭%৩১.০৩Δ −১৮৩.৫৪−৮৫.৫৪%
এর মধ্যে WPR³ ফাইল লেখা, MiB১৬৪.০০ভিত্তি১৭২.০০Δ +৮.০০+৪.৮৮%৭২.০০Δ −৯২.০০−৫৬.১০%১৫.০০Δ −১৪৯.০০−৯০.৮৫%
ডিস্ক থেকে পড়ার অপারেশন৬৩৪ভিত্তি৫,২৮১Δ +৪,৬৪৭+৭৩২.৯৭%৪,২৪১Δ +৩,৬০৭+৫৬৮.৯৩%৮৩৬Δ +২০২+৩১.৮৬%
ডিস্কে লেখার অপারেশন৫,৬৯০ভিত্তি২,৪১০Δ −৩,২৮০−৫৭.৬৪%১,২৫০Δ −৪,৪৪০−৭৮.০৩%১,৭৮৩Δ −৩,৯০৭−৬৮.৬৬%
সময়সীমার দৈর্ঘ্য, সেকেন্ড২৯৯.৯৮৬২৯৯.৯৯৯৩০০.০০৬৩০০.০১৬

প্রতিটি মানের নিচে একই পর্যায়ে Clean-এর তুলনায় Δ দেখানো হয়েছে: সারির এককে পরম পার্থক্য এবং শতাংশে আপেক্ষিক পরিবর্তন। CPU লোডের পরম পার্থক্য শতাংশ-পয়েন্টে (প.প.) দেখানো হয়েছে। ঋণাত্মক মান সূচক হ্রাস, ধনাত্মক মান বৃদ্ধি বোঝায়; উইন্ডোর সময়কাল ডেল্টা ছাড়া দেখানো হয়েছে। সূত্র: Δ = этап − Clean, Δ% = (этап / Clean − 1) × 100।

CPU হিসাব করা হয়েছে CPU Usage (Sampled) নমুনা থেকে, ব্যবধানের সময়কাল বিবেচনায় নিয়ে এবং 16টি লজিক্যাল প্রসেসরের ওপর গড় করে। CPU সময়ের অনুমান = গড় লোড × উইন্ডোর সময়কাল × 16 / 100। পিক প্রায় এক সেকেন্ডের ব্যবধান থেকে নেওয়া হয়েছে; প্রান্তের ব্যবধানগুলো ছোট হতে পারে। ইভেন্টগুলো সম্পূর্ণ উইন্ডোর মধ্যে গণনা করা হয়েছে; প্রক্রিয়া ও থ্রেড উইন্ডোর শেষে গণনা করা হয়েছে, Idle বাদ দিয়ে। একই প্রক্রিয়া পুনরায় তৈরি হলেও চালুর সংখ্যা গণনায় ধরা হয়েছে।

¹ মেমরি ও হ্যান্ডেল: ETL শেষ হওয়ার সময়, শেষ মার্কারের 0,28–0,65 সেকেন্ড পরে প্রক্রিয়ার কাউন্টারগুলোর স্ন্যাপশট নেওয়া হয়েছে। সঠিক সময়ের ব্যবধান JSON-এ সংরক্ষিত আছে। ওয়ার্কিং সেটের যোগফলে শেয়ার করা পেজ একাধিকবার গণনা হয় এবং এটি ব্যবহৃত ফিজিক্যাল RAM-এর সমান নয়। প্রক্রিয়াগুলোর Commit হলো বরাদ্দ করা ভার্চুয়াল মেমরি, যার জন্য RAM বা পেজ ফাইলের জায়গা নিশ্চিত করতে হয়; এটি পেজ ফাইলে প্রকৃতপক্ষে লেখা ডেটার পরিমাণ নয়। এই যোগফলগুলো কার্নেল, ড্রাইভার এবং ফাইল ক্যাশের সম্পূর্ণ মেমরি বর্ণনা করে না।

² Hard faults বলতে RAM-এ অনুপস্থিত পেজ ডিস্ক থেকে লোড করাকে বোঝায়, যার মধ্যে ফাইলের পেজও রয়েছে। এগুলো হার্ডওয়্যার মেমরি ত্রুটি নয়। DPC এবং ISR ইভেন্টের হার দেখায়, ইনপুট ল্যাটেন্সি বা সেগুলো প্রক্রিয়াকরণের সময়কাল নয়।

³ WPR রাইট রেকর্ডারের ফাইলের নাম দেখে আলাদা করা হয়েছে। এটি মোট ডিস্ক রাইটের মধ্যেই অন্তর্ভুক্ত। ডিস্ক মেট্রিকগুলোতে পরিমাপের টুলের কার্যকলাপও রয়েছে; এগুলো অ্যাপ্লিকেশনের লোডের বিশুদ্ধ অনুমান নয়।

চারটি পর্যায়ে সাইন-ইন করার পর এবং নিষ্ক্রিয় অবস্থায় CPU-এর গড় নমুনাভিত্তিক ব্যবহার। স্কেল শূন্য থেকে শুরু।

Clean ও Expert Hardcore-এর তুলনায়, সাইন-ইন করার পর CPU-এর নমুনাভিত্তিক ব্যবহার প্রায় 5,3 গুণ কমেছে, আর নিষ্ক্রিয় অবস্থায় 6,8 গুণ কমেছে। নিষ্ক্রিয় অবস্থায় কনটেক্সট সুইচ প্রায় 5,8 গুণ কমেছে; উইন্ডোর শেষে প্রক্রিয়ার সংখ্যা: 153 → 64। এগুলো নির্দিষ্ট পরিমাপ করা মেট্রিকের অনুপাত, Windows-এর একক «গতি বৃদ্ধির» গুণক নয়।

নিষ্ক্রিয় অবস্থায় Safe কেন বেশি লোড তৈরি করেছে

Заголовок раздела « নিষ্ক্রিয় অবস্থায় Safe কেন বেশি লোড তৈরি করেছে»

Safe-এর নিষ্ক্রিয় সময়ের শেষ মিনিটে mscorsvw.exe এবং ngen.exe চলছিল। mscorsvw.exe-এর জন্য প্রায় 56,4 CPU সেকেন্ড লেগেছে। মিনিটভিত্তিক গড় CPU: 0,40 → 0,20 → 0,19 → 0,19 → 7,49%। ফলে প্রথম চার মিনিট তুলনামূলক শান্ত থাকলেও পুরো উইন্ডোটি Clean-এর চেয়ে বেশি লোডযুক্ত হয়েছে।

প্রতিটি নিষ্ক্রিয় উইন্ডোর পাঁচ মিনিটে CPU। Safe-এ শেষ মিনিটে স্পাইক দেখা যায়; ফলাফল থেকে কোনো মান বাদ দেওয়া হয়নি।

এই স্পাইকটি মূল টেবিলে রাখা হয়েছে। একটি ধারাবাহিক সিরিজ থেকে কোনো মোডের স্থায়ী প্রভাবকে এককালীন ব্যাকগ্রাউন্ড কাজ এবং সময়ের সঙ্গে Windows-এর অবস্থার পরিবর্তন থেকে আলাদা করা যায় না।

মেমরি ও ডিস্কের মেট্রিক কীভাবে পড়বেন

Заголовок раздела « মেমরি ও ডিস্কের মেট্রিক কীভাবে পড়বেন»

মোট ডিস্ক রাইটের মধ্যে WPR-এর নিজের রাইটও রয়েছে। উদাহরণস্বরূপ, Clean-এর নিষ্ক্রিয় অবস্থায় 214,57 MiB রাইটের মধ্যে 164 MiB সরাসরি WPR রেকর্ডার ফাইলে লেখা হয়েছে। এই অংশটি টেবিলে আলাদা সারিতে দেখানো হয়েছে। পরীক্ষার ফোল্ডারটি OneDrive-এ ছিল; সিঙ্ক্রোনাইজেশনের প্রভাব আলাদাভাবে বিচ্ছিন্ন করা হয়নি। এই প্রকাশনায় নেটওয়ার্কের গতি ও বিদ্যুৎ খরচের তুলনা করা হয়নি।

দুটি রানের গড় · Clean-এর তুলনায় Δ
সূচকCleanSafe AdvancedAdvanced AdvancedExpert Hardcore
গড় FPS৮৮৮.২৯ভিত্তি৯১১.১৯Δ +২২.৯১+২.৫৮%৯১৪.৫৬Δ +২৬.২৮+২.৯৬%৯০৮.০৮Δ +১৯.৭৯+২.২৩%
P1 FPS২৯৬.৭৩ভিত্তি৩০৪.৪২Δ +৭.৬৯+২.৫৯%৩০৮.৫৫Δ +১১.৮২+৩.৯৮%৩১২.১৫Δ +১৫.৪২+৫.২০%
P0,1 FPS২৫৯.১৫ভিত্তি২৬৫.৯০Δ +৬.৭৬+২.৬১%২৬০.২৮Δ +১.১৩+০.৪৪%২৬৪.২৯Δ +৫.১৪+১.৯৮%
1% কম: ধীর ফ্রেমের গড়, FPS২৭৫.৫০ভিত্তি২৮৩.৬৩Δ +৮.১৪+২.৯৫%২৮৩.৪১Δ +৭.৯১+২.৮৭%২৮৮.২১Δ +১২.৭১+৪.৬১%
গড় ফ্রেম টাইম, মি.সে.১.১২৬ভিত্তি১.০৯৭Δ −০.০২৮−২.৫১%১.০৯৩Δ −০.০৩২−২.৮৭%১.১০১Δ −০.০২৫−২.১৮%
ফ্রেম টাইমের P99, মি.সে.৩.৩৭০ভিত্তি৩.২৮৫Δ −০.০৮৫−২.৫৩%৩.২৪১Δ −০.১২৯−৩.৮৪%৩.২০৪Δ −০.১৬৭−৪.৯৫%
পরপর ফ্রেমের গড় পার্থক্য, মি.সে.০.৩৫১ভিত্তি০.৩৩৮Δ −০.০১৩−৩.৬৪%০.৩৩৫Δ −০.০১৬−৪.৫৩%০.৩২৯Δ −০.০২২−৬.৩০%
গড় FPS: দুটি রানের পরিসর৮৮৪.৮৫
– ৮৯১.৭২
৯০৮.৭৯
– ৯১৩.৫৯
৯১৪.৫৫
– ৯১৪.৫৭
৯০৭.৫৭
– ৯০৮.৫৯

শূন্য থেকে শুরু হওয়া স্কেলে চারটি পর্যায়ের গড় FPS। বিন্দুগুলো প্রতিটি আলাদা রান দেখায়।

Advanced Advanced-এ গড় FPS ছিল সর্বোচ্চ: 914,56, Clean-এর 888,29-এর তুলনায় +2,96%। Expert Hardcore-এর গড় FPS সামান্য কম হলেও P1 ছিল সর্বোচ্চ: 312,15, 296,73-এর তুলনায় +5,20%। সবচেয়ে আক্রমণাত্মক পর্যায়টি সব মেট্রিকে সেরা ছিল না।

প্রতিটি রানের গড় FPS হলো 1000 / среднее время кадра в мс। P1 হলো 1000 / P99 времени кадра; P99 সাজানো ফ্রেমের ওপর লিনিয়ার ইন্টারপোলেশন করে হিসাব করা হয়। প্রতিটি পর্যায়ের ফলাফল হলো দুটি ফলাফলের গড়। মানগুলোর নিচে Clean-এর তুলনায় পরম ও আপেক্ষিক ডেল্টা দেখানো হয়েছে। FPS-এর ক্ষেত্রে বেশি মানে দ্রুত, আর ফ্রেম টাইমের ক্ষেত্রে কম মানে দ্রুত। 1% low সারিটি আলাদাভাবে 1000 / среднее время самых медленных 1% кадров হিসেবে হিসাব করা হয়েছে এবং এটি P1-এর সমান নয়।

আটটি রান এবং দীর্ঘ ফ্রেম
সব রান, ধীর ফ্রেম বাদ না দিয়ে
পর্যায় / রানফ্রেমগড় FPSP1 FPSP99, মি.সে.সবচেয়ে দীর্ঘ ফ্রেম, মি.সে.
Clean / 1৯৩,৬৩১৮৯১.৭২২৯৯.৭০৩.৩৩৭১১.৯৫৬
Clean / 2৯২,৯১১৮৮৪.৮৫২৯৩.৭৫৩.৪০৪১২.৪৫৩
Safe Advanced / 1৯৫,৯২৮৯১৩.৫৯৩০৬.০০৩.২৬৮১০.৪৮৮
Safe Advanced / 2৯৫,৪২৪৯০৮.৭৯৩০২.৮৪৩.৩০২৭.৩৮৫
Advanced Advanced / 1৯৬,০৩০৯১৪.৫৫৩০৭.৭৭৩.২৪৯১১.১৭৭
Advanced Advanced / 2৯৬,০৩১৯১৪.৫৭৩০৯.৩২৩.২৩৩৮.৪৪৮
Expert Hardcore / 1৯৫,২৯৫৯০৭.৫৭৩১০.০৭৩.২২৫৯.১৪৪
Expert Hardcore / 2৯৫,৪০৩৯০৮.৫৯৩১৪.২৩৩.১৮২৮.৮৯৪

সব ফ্রেম ব্যবধান ধনাত্মক, সময়ক্রম একমুখী। দীর্ঘ ফ্রেমগুলো সংরক্ষিত আছে। ফ্রেমগুলো পরীক্ষার স্বাধীন পুনরাবৃত্তি নয়: এখানে প্রতি পর্যায়ে মাত্র দুটি FPS রান রয়েছে। টেবিলের পরিসর এই দুটি রানের পার্থক্য দেখায়, আস্থার ব্যবধান নয়।

GPU-এর গড় লোড ছিল প্রায় 74–76% এবং পিক ছিল 95–96% পর্যন্ত। এই ডেটা থেকে পরিস্থিতির প্রতিটি অংশকে একান্তভাবে CPU-নির্ভর বলা যায় না। CapFrameX-এর PcLatency ফিল্ডটি «মাউস নড়াচড়া → স্ক্রিনে আলো» ধরনের ফিজিক্যাল ল্যাটেন্সি হিসেবে ব্যবহার করা হয়নি।

CapFrameX-এর Variances ট্যাবের নীতি ব্যবহার করা হয়েছে: পরপর দুটি ফ্রেমের ফ্রেম টাইমের পার্থক্যের পরম মান |tᵢ − tᵢ₋₁|, মিলিসেকেন্ডে। জোড়াগুলো পাঁচটি ব্যবধানে ভাগ করা হয়েছে: <2, 2–<4, 4–<8, 8–<12 এবং ≥12 мс। এটি পরপর ফ্রেমের ওঠানামার একটি মেট্রিক; এখানে ms²-এ পরিসংখ্যানগত ভ্যারিয়েন্স হিসাব করা হয়নি। ব্যবধানের সীমানা CapFrameX v1.8.6-এর সোর্স কোডের সঙ্গে মিলিয়ে দেখা হয়েছে।

CapFrameX-এর ব্যবধান অনুযায়ী পরপর ফ্রেমের পার্থক্যের বণ্টন। উপরে সম্পূর্ণ 0–100% স্কেল, নিচে 2 ms থেকে শুরু হওয়া ওঠানামা আলাদাভাবে 0–8% স্কেলে দেখানো হয়েছে।

Expert Hardcore-এ 2 ms বা তার বেশি পার্থক্য থাকা জোড়ার অনুপাত 4,091%, Clean-এর 5,879%-এর তুলনায়। এটি −1,787 প.প., অথবা Clean-এর তুলনায় −30,4%। Safe Advanced-এ হ্রাস 18,0%, আর Advanced Advanced-এ 26,1%। এই শতাংশগুলো 2 ms বা তার বেশি পরপর ফ্রেমের ওঠানামার অনুপাত বোঝায়, FPS বৃদ্ধি বা লক্ষ্যভেদের নির্ভুলতা নয়।

ফ্রেম জোড়ার অনুপাত, % · Clean-এর তুলনায় Δ, পয়েন্টে
পরপর ফ্রেমের পার্থক্যCleanSafe AdvancedAdvanced AdvancedExpert Hardcore
<2 মি.সে.৯৪.১২১৪%৯৫.১৭৭৪%Δ +১.০৫৬১ পয়েন্ট৯৫.৬৫৮১%Δ +১.৫৩৬৭ পয়েন্ট৯৫.৯০৮৭%Δ +১.৭৮৭৩ পয়েন্ট
2–<4 মি.সে.৫.৮৫৪০%৪.৮০৩৮%Δ −১.০৫০২ পয়েন্ট৪.৩২২৬%Δ −১.৫৩১৩ পয়েন্ট৪.০৬৯৩%Δ −১.৭৮৪৭ পয়েন্ট
4–<8 মি.সে.০.০১৬৬%০.০১৬২%Δ −০.০০০৪ পয়েন্ট০.০১৭২%Δ +০.০০০৬ পয়েন্ট০.০২১০%Δ +০.০০৪৪ পয়েন্ট
8–<12 মি.সে.০.০০৭৫%০.০০২৬%Δ −০.০০৪৯ পয়েন্ট০.০০২১%Δ −০.০০৫৪ পয়েন্ট০.০০১০%Δ −০.০০৬৫ পয়েন্ট
≥12 মি.সে.০.০০০৫%০.০০০০%Δ −০.০০০৫ পয়েন্ট০.০০০০%Δ −০.০০০৫ পয়েন্ট০.০০০০%Δ −০.০০০৫ পয়েন্ট

প্রতিটি পর্যায়ে দুটি রানের জোড়ার সংখ্যা একত্র করা হয়েছে, তবে একটি রানের শেষ ফ্রেমের সঙ্গে অন্য রানের প্রথম ফ্রেম জোড়া করা হয়নি। হর হলো দুই রানের N − 1-এর যোগফল। তাই অনুপাতগুলো জোড়ার সংখ্যা অনুযায়ী ওজনযুক্ত; FPS-এর দুটি মানের গড়ের মতো নয়। JSON ও CSV-তে সঠিক সংখ্যা সংরক্ষিত আছে; টেবিলে অনুপাত চার দশমিক ঘর পর্যন্ত রাউন্ড করা হয়েছে। CapFrameX এগুলো আরও আগে রাউন্ড করে, তাই প্রদর্শিত শেষ অঙ্কগুলো ভিন্ন হতে পারে।

মূল হ্রাসটি 2–<4 ms ব্যবধানে। Expert Hardcore-এ 4–<8 ms ওঠানামার অনুপাত Clean-এর চেয়ে সামান্য বেশি: 0,0210% বনাম 0,0166%। বিরল ওঠানামাসহ সব ব্যবধান সংরক্ষিত আছে। দুটি রান থেকে এই পরিবর্তনের পুনরাবৃত্তিযোগ্যতা নির্ধারণ করা যায় না।

লক্ষ্যভেদের জন্য এর অর্থ: এই বেঞ্চমার্কে 2 ms সীমা অনুযায়ী ফ্রেমের মধ্যবর্তী ব্যবধান আরও সমান হয়েছে। এতে লক্ষ্যচিহ্নের নড়াচড়া দৃশ্যত মসৃণ হওয়ার সম্ভাব্য সুবিধা কেবল অনুমান; ফ্রেম ব্যবধানের রেকর্ডিং লক্ষ্যভেদের নির্ভুলতা, মাউসের নড়াচড়া বা ছবি প্রদর্শিত হওয়া পর্যন্ত ল্যাটেন্সি মাপে না। এই সিরিজের ভিত্তিতে «লক্ষ্যভেদ অনেক ভালো হবে»—এমন প্রতিশ্রুতি দেওয়া যায় না।

এই ধারাবাহিক সিরিজে সাইন-ইন করার পর ব্যাকগ্রাউন্ড কার্যকলাপ কমেছে। নির্বাচিত CS2 পরিস্থিতিতে পরবর্তী তিনটি পর্যায়েই প্রস্তুত করা Clean-এর তুলনায় গড় FPS বেশি ছিল। এই পরীক্ষাব্যবস্থায় ব্যবহারিক ফলাফল: গড় FPS-এ প্রায় 2–3% বৃদ্ধি, তবে Advanced এবং Expert Hardcore-এর শক্তির দিক আলাদা।

এই গবেষণা কোনো একক সেটিংয়ের অবদান, সর্বজনীন বৃদ্ধির পরিমাণ, Windows চালু হওয়ার সময় বা ফিজিক্যাল ইনপুট ল্যাটেন্সি নির্ধারণ করে না। Expert Hardcore-এ পাওয়ার প্ল্যান পরিবর্তন করা হয়েছে, তাই পুরো পর্যায়টিকেই একসঙ্গে তুলনা করা হয়েছে। প্রক্রিয়ার সংখ্যা কমা নিজে থেকে গেমিং পারফরম্যান্সের মাপকাঠি নয়।

সীমাবদ্ধতা: একটি PC, পর্যায়গুলোর নির্দিষ্ট ক্রম, প্রতি পর্যায়ে একটি সম্পূর্ণ WPR রেকর্ডিং, দুটি FPS রান, ক্যাপচার ম্যানুয়ালি শুরু করা, বাইনারি ফাইলের হ্যাশ সংরক্ষণ না করা Debug বিল্ড। ক্রম, ক্যাশ ওয়ার্ম-আপ এবং ব্যাকগ্রাউন্ড রক্ষণাবেক্ষণের প্রভাব অপ্টিমাইজেশন থেকে আলাদা করা হয়নি। Clean-এর নিষ্ক্রিয় সময়ে Task Manager-ও অল্প সময়ের জন্য চালু হয়েছিল; কোনো অংশ বাদ না দিয়ে পুরো উইন্ডো রাখা হয়েছে। এই সিরিজে স্বাধীনভাবে পুনরাবৃত্তি বা Clean-এ ফিরে যাওয়ার নিয়ন্ত্রণ পরীক্ষা নেই।

FPS বাড়ানোর জন্য অ্যান্টিভাইরাস বন্ধ করার পরামর্শ দেওয়া হয় না। এই সিরিজে পরিবর্তনের সম্পূর্ণ সেটগুলো তুলনা করা হয়েছে; «সুরক্ষা চালু / বন্ধ»—এই একক ভেরিয়েবল নিয়ে আলাদা পরীক্ষা করা হয়নি। তাই এটি অ্যান্টিভাইরাসের FPS-এ কোনো প্রভাব নেই—এমন প্রমাণ দেয় না, কিংবা এটি বন্ধ করলে মেমরি কতটা সাশ্রয় হয় তাও আলাদাভাবে মাপে না।

Microsoft রিয়েল-টাইম সুরক্ষা চালু রাখার পরামর্শ দেয়। উল্লেখযোগ্য লোড দেখা গেলে নির্দিষ্ট কারণ খুঁজে বের করতে Microsoft Defender-এর পারফরম্যান্স বিশ্লেষণ ব্যবহার করা যায়।

এই পরিমাপগুলোর মধ্যে Expert Hardcore-এর পর আগের অবস্থা পুনরুদ্ধার করা যাচাই করা হয়নি। স্বাধীন অবস্থা নিয়ে পুনরায় পরীক্ষা করতে হলে আগে থেকে প্রস্তুত করা Clean ইমেজ পুনরুদ্ধার করুন এবং পুনরুদ্ধারের ধাপগুলো নথিভুক্ত করুন। রোলব্যাকের সাধারণ সীমাবদ্ধতা BoosterX-এর পুনরুদ্ধার-সংক্রান্ত সীমাবদ্ধতা-তে বর্ণনা করা হয়েছে।

সব ডেটা ZIP ডাউনলোড করুন ৩০১.৭ MiB

8 ETL · 8 CapFrameX JSON · টেবিল, চার্ট ও পুনর্গণনার স্ক্রিপ্ট। ফলাফল দেখতে আর্কাইভের ভেতরের README.html খুলুন। মূল রেকর্ডিং সম্পাদনা ছাড়াই সংরক্ষিত হয়েছে। infinst.exe নামের দুটি ফাইলও CS2 পরীক্ষার অংশ।

আর্কাইভের SHA-256
7f20104f7eb46428e5e4f383515653b1320827be39fc171d1b5590210d0fbcdd

WPR, CSV · সব FPS রান, CSV · Frametime Variance, CSV · গণনা, JSON · পুনর্গণনার স্ক্রিপ্ট

একটি আর্কাইভে চারটি সম্পূর্ণ WPR পর্যায়ের মূল ডিরেক্টরি, Expert Hardcore-এর অসম্পূর্ণ প্রচেষ্টা, CapFrameX-এর আটটি মূল JSON, ব্যবহৃত রেকর্ডিং স্ক্রিপ্ট, পদ্ধতি, টেবিল, গ্রাফ এবং পুনর্গণনার সোর্স ফাইল একত্র করা হয়েছে। পুরোনো smoke test এবং সেগুলোর পুনরাবৃত্তি করা সার্ভিস আর্কাইভ অন্তর্ভুক্ত করা হয়নি। মূল ডিরেক্টরিগুলোর ভেতরে পুরোনো যাচাই-স্ট্যাটাস থাকলেও ETL থেকে এখানে দেখানো হিসাব বদলায় না।

ETL নিজে বিশ্লেষণ করতে Windows Performance Toolkit প্রয়োজন; মূল গেম রেকর্ডিংয়ের জন্য CapFrameX ব্যবহার করা যায়। analysis/analyze.py স্ক্রিপ্টটি Python 3 এবং WPT 10+ ব্যবহার করে; এটি রেকর্ডিং চালায় না বা সিস্টেমে পরিবর্তন করে না। নির্দেশনা README.html-এ রয়েছে। চেকসাম ফাইল অপরিবর্তিত আছে কি না যাচাই করতে সাহায্য করে; এগুলো পরীক্ষার শর্তগুলো সত্যিই অনুসরণ করা হয়েছে—তা প্রমাণ করে না।

সিস্টেম ট্রেসগুলো মূল অবস্থায় সংরক্ষিত আছে: এতে পরীক্ষার ইনস্টলেশন-সংক্রান্ত প্রযুক্তিগত তথ্য রয়েছে, যেমন প্রক্রিয়া, স্থানীয় পাথ এবং সিস্টেম আইডেন্টিফায়ার। আর্কাইভটি পরিচয়মুক্ত করা হয়েছে বলে দাবি করা হচ্ছে না। BoosterX অ্যাপ্লিকেশনের সোর্স কোড এবং তৃতীয় পক্ষের এক্সিকিউটেবল ফাইল এতে অন্তর্ভুক্ত নয়।

সর্বশেষ যাচাই: 2026-10-25। প্রথম সংস্করণ প্রকাশিত হয়েছে অক্টোবরের 24 তারিখে: একটি ফিজিক্যাল PC-তে চারটি পর্যায়, উন্মুক্ত মূল পরিমাপ এবং পুনর্গণনা। অক্টোবরের 25 তারিখে Clean-এর তুলনায় ডেল্টা, বিস্তৃত FPS টেবিল এবং Frametime Variance যোগ করা হয়েছে। গবেষণাটি BoosterX-এর ডেভেলপার প্রস্তুত করেছেন। স্বাধীন যাচাইয়ের জন্য মূল রেকর্ডিং, পরীক্ষার শর্ত এবং পুনর্গণনার স্ক্রিপ্ট প্রকাশ করা হয়েছে।