अपने विंडोज टाइमर या बर्बाद मेगावाट ओवरक्लॉक क्यों नहीं

डिफ़ॉल्ट विंडोज टाइमर की अवधि 15.6 एमएस है - यह प्रति सेकंड 64 बार टिक करता है। जब प्रोग्राम टाइमर की आवृत्ति बढ़ाता है, तो ऊर्जा की खपत बढ़ जाती है, जो बैटरी की खपत को प्रभावित करती है। यह कंप्यूटर की कंप्यूटिंग शक्ति का भी उपभोग करता है, और इससे भी अधिक मैंने सोचा था - अर्थात, कंप्यूटर धीमा चलना शुरू कर देता है! यही कारण है कि कई वर्षों के लिए, माइक्रोसॉफ्ट ने डेवलपर्स को टाइमर आवृत्ति को बढ़ाने से हतोत्साहित किया है।
फिर, लगभग हर बार जब मैं टाइमर ओवरक्लॉक देखता हूं, तो क्या इसे माइक्रोसॉफ्ट के एक कार्यक्रम द्वारा बुलाया जाता है?

पता लगाने के लिए विंडोज टाइमर की वर्तमान आवृत्ति sysinternals से घड़ी की उपयोगिता का उपयोग करके काफी सरल है।

ClockRes v2.0 - सिस्टम घड़ी रिज़ॉल्यूशन देखें
कॉपीराइट 2009 मार्क रोसिनोविच
SysInternals - www.sysinternals.com

अधिकतम टाइमर अंतराल: 15.600 एमएस
न्यूनतम टाइमर अंतराल: 0.500 एमएस
वर्तमान टाइमर अंतराल: 1.000 एमएस

कंप्यूटर की बैटरी जीवन को बढ़ाने के लिए, वर्तमान टाइमर अवधि (जिसे टाइमबिनपिरियोड फ़ंक्शन के साथ बदला जा सकता है) को 15% एमएस किया जाना चाहिए; लेकिन, जैसा कि आप ऊपर देखते हैं, कुछ प्रोग्राम ने इसे 1 एमएस से बदल दिया, जो कि प्रति सेकंड 936 अतिरिक्त टिक के बराबर है।

दोषी खोज - WPF

आवृत्ति बढ़ाने में अपराधी को खोजने की प्रक्रिया इतनी स्पष्ट नहीं है, लेकिन अभी भी काफी सरल है। व्यवस्थापक के कमांड प्रॉम्प्ट पर, टाइप करें

powercfg -energy अवधि 5

और ऊर्जा-रिपोर्ट। html फ़ाइल वर्तमान निर्देशिका में दिखाई देती है, जिसमें हम, विशेष रूप से, पढ़ते हैं:

इस प्रक्रिया में सबसे कम प्लेटफॉर्म टाइमर सेटिंग के लिए जिम्मेदार मॉड्यूल का ढेर।
आवश्यक अवधि 10000
अनुरोध करने की प्रक्रिया आईडी 3932
अनुरोध पथ प्रक्रिया
C: \ Program Files (x86) \ Microsoft Visual Studio 11.0 \ Common7 \ IDE \ devenv.exe
मॉड्यूल स्टैक कॉलिंग
C: \ Windows \ SysWOW64 \ ntdll.dll
C: \ Windows \ SysWOW64 \ winmm.dll
C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ WPF \ wpfgfx_v0400.dll
C: \ Windows \ SysWOW64 \ kernel32.dll
C: \ Windows \ SysWOW64 \ ntdll.dll

इसलिए, विज़ुअल स्टूडियो 11 ने WPF के उपयोग के माध्यम से, 1 एमएस के अंतराल का अनुरोध किया, जो कि रिपोर्ट में 100 एनएस के बराबर माप की कुछ भ्रामक इकाई का उपयोग करके इंगित किया गया है। यह WPF के साथ एक ज्ञात मुद्दा है ; विजुअल स्टूडियो के सभी संस्करण समय-समय पर इस तरह का व्यवहार करते हैं और, जाहिरा तौर पर, WPF का उपयोग करने वाला कोई भी एप्लिकेशन समस्या का स्रोत हो सकता है। आवृत्ति बढ़ने से समझ में आ सकता है जब कोई प्रोग्राम आउटपुट की निरंतर फ्रेम दर को बनाए रखने की कोशिश करता है, हालांकि, यह WPF को सही नहीं ठहराता है, क्योंकि यह कोई एनीमेशन नहीं होने पर भी उच्च टाइमर आवृत्ति को बनाए रखता है।

अपराधी की तलाश करें - SQL सर्वर

मेरे कंप्यूटर पर आवृत्ति को बढ़ाने के लिए एक और प्रक्रिया अक्सर sqlservr.exe है। मुझे लगता है कि यह Visual Studio द्वारा स्थापित किया गया था, लेकिन मुझे इसके बारे में निश्चित नहीं है, मुझे यकीन नहीं है कि इसका उपयोग किया गया है या नहीं। किसी भी स्थिति में, SQL सर्वर को टाइमर की आवृत्ति में वृद्धि नहीं करनी चाहिए; अगर इस तरह से यह एप्लिकेशन के प्रदर्शन को बढ़ाने वाला है, तो यह एक बैसाखी की तरह है। और, WPF के मामले में, आवृत्ति में वृद्धि केवल तभी आवश्यक है जब सर्वर डेटा को संसाधित करने में व्यस्त है, और लगातार नहीं।

प्लेटफ़ॉर्म टाइमर संकल्प: उत्कृष्ट टाइमर अनुरोध
एक कार्यक्रम या सेवा ने प्लेटफ़ॉर्म के अधिकतम टाइमर रिज़ॉल्यूशन की तुलना में एक टाइमर रिज़ॉल्यूशन का अनुरोध किया है।
आवश्यक अवधि 10000
अनुरोध प्रक्रिया आईडी 2384
पथ / डिवाइस \ HarddiskVolume1 \ Program Files \ Microsoft SQL सर्वर \ MSSQL10.MSSQLSERVER \ MSSQL \ Binn \ sqlservr.exe का अनुरोध करना

अपराधी की खोज करें - quartz.dll

मेरे पास पॉवरफग रिपोर्ट से संबंधित प्रविष्टि नहीं है, लेकिन C: \ Windows \ System32 \ quartz.dll टाइमर आवृत्ति समस्याओं का एक और स्रोत है। मैं वास्तव में नहीं जानता कि यह क्वार्ट्स क्या है (ठीक है, हम जानते हैं कि यह Microsoft DirectShow --x .x । ) से अधिक कुछ भी नहीं है, लेकिन मैंने देखा कि कभी-कभी यह ऊर्जा बर्बाद करता है।

दोषी खोज - क्रोम

Microsoft उत्पाद आमतौर पर अपराधी होते हैं, लेकिन मैं उनमें Google Chrome जोड़ता हूं। जब मैं क्रोम शुरू करता हूं, तो यह लगातार टाइमर की आवृत्ति बढ़ाकर 1000 हर्ट्ज कर देता है, यहां तक ​​कि जब कंप्यूटर बैटरी पावर पर चल रहा होता है, और मैं एक साधारण HTML पेज देख रहा हूं। यहां Chrome अपराध पर कब्जा करने वाला एक स्क्रीनशॉट है।

अपराधी की तलाश करें - svchost.exe

कभी-कभी svchost.exe टाइमर आवृत्ति को 100 हर्ट्ज तक बढ़ा देता है। यह, निश्चित रूप से, 1000 हर्ट्ज जितना डरावना नहीं है, लेकिन फिर भी कष्टप्रद है। यह विशेष रूप से दुखद है कि मैं यह निर्धारित नहीं कर सकता कि कौन सी सेवा यह करती है।

सामान्य त्रासदी - अधिकतम आवृत्ति जीतती है

विंडोज टाइमर एक वैश्विक संसाधन है, यह पूरे सिस्टम के लिए समान आवृत्ति पर टिक करता है। यह पता चला है कि अगर कुछ प्रोग्राम टाइमर की आवृत्ति बढ़ाते हैं, तो यह पूरे सिस्टम के व्यवहार को प्रभावित करता है।
जब कोई प्रक्रिया timeBeginPeriod फ़ंक्शन को कॉल करती है, तो यह आवृत्ति अनुरोध तब तक मान्य रहता है जब तक कि उसे समय-समय पर रद्द नहीं किया जाता है और जब तक कि अनुप्रयोग समाप्त नहीं हो जाता है। अधिकांश प्रोग्राम (नीचे मेरे परीक्षण सहित) कभी भी टाइमएंडपिरोड नहीं कहते हैं, जो विंडोज सिस्टम क्लीनअप टूल पर निर्भर है। यह काम करता है और उन अनुप्रयोगों के लिए काफी उचित है जो पूरे निष्पादन में एक बढ़ी हुई टाइमर आवृत्ति की आवश्यकता होती है। अन्यथा, timeEndPeriod का उपयोग करना एक अच्छा विचार है। Microsoft की सिफारिश पर, विराम मोड में वीडियो एप्लिकेशन और ट्रे में न्यूनतम गेम दूसरे प्रकार के अनुप्रयोगों से संबंधित हैं। यहां आप उन वेब ब्राउज़रों को भी शामिल कर सकते हैं, जिन्हें वर्तमान में उच्च आवृत्ति टाइमर या बैटरी पावर पर चलने की आवश्यकता नहीं है।

क्या यह महत्वपूर्ण है?

मेरा मुख्य कंप्यूटर एक लैपटॉप है। हर दिन मैं इसे बस में उपयोग करता हूं और प्रोसेसर को 1000 बार प्रति सेकंड अनावश्यक कॉल के बजाय उपयोगी कुछ पर बैटरी खर्च करना पसंद करता हूं।
माइक्रोसॉफ्ट का मानना ​​है कि यह महत्वपूर्ण है। वे कहते हैं : "हमारी स्थिति विंडोज पीसी की ऊर्जा दक्षता में लगातार सुधार करने के लिए बनी हुई है" और फिर भी, 4 साल बाद भी, वे खुद ही अपने निर्देशों का पालन नहीं करते हैं और खुद की चेतावनी पर ध्यान नहीं देते हैं: "कुछ एप्लिकेशन टाइमर की अवधि को 1 एमएस तक कम कर देते हैं। , जिससे मोबाइल प्रणाली के परिचालन समय में 25% की कमी आती है। "
ऊर्जा की खपत को मापने का एक सुविधाजनक तरीका इंटेल पावर गैजेट की उपयोगिता है। समर्थित इंटेल प्रोसेसर पर, यह 0.01 वॉट की सटीकता के साथ वास्तविक समय में प्रोसेसर पैकेजिंग द्वारा खपत की गई शक्ति को दिखाएगा। मेरे सैंडी ब्रिज-आधारित लैपटॉप पर, उपयोगिता टाइमर आवृत्ति में वृद्धि के साथ 0.3 डब्ल्यू की वृद्धि दर्शाती है, जो मानक प्रोसेसर पैकेजिंग खपत का लगभग 10% है; पूरी प्रणाली के संबंध में, प्रतिशत, निश्चित रूप से, कम होगा।
0.3 वाट की वृद्धि इतनी बड़ी नहीं लग सकती है, लेकिन कुछ बिंदु हैं जो आपको इसे गंभीरता से लेते हैं। सबसे पहले, यदि आपका प्रोग्राम चलता है, तो कहें, 33 मिलियन कंप्यूटर (क्रोम के लिए, यह संभवतः एक कम अनुमान है), टाइमर की आवृत्ति बढ़ने से लगभग 10 मेगा वाट ऊर्जा की हानि होगी। दूसरे, समस्या का महत्व केवल समय के साथ बढ़ेगा। एक बेहतर एकीकृत टाइमर के साथ नए प्रोसेसर लगातार कॉल पर अधिक कंप्यूटिंग शक्ति खर्च करेंगे।

तेज़ टाइमर प्रदर्शन को नीचा दिखाते हैं

व्यवधान में बाधा डालने से कंप्यूटर के कुछ संसाधनों में वृद्धि होती है, इसलिए समय की प्रति यूनिट उनकी संख्या बढ़ने से इसकी गति कुछ हद तक धीमी हो जानी चाहिए। मैंने एक परीक्षण कार्यक्रम लिखकर इस सिद्धांत का परीक्षण किया जो गतिविधि चक्र को घुमाता है और हर सेकंड इसके निष्पादन की गति को रिपोर्ट करता है। जब कार्यक्रम चल रहा था, मैंने प्रदर्शन पर इसके प्रभाव को देखने के लिए टाइमर की आवृत्ति को बदल दिया।
प्रभाव महत्वपूर्ण था।
मैंने दो कंप्यूटरों पर त्वरित परीक्षण किया, इसलिए सटीक संख्याओं को बहुत गंभीरता से नहीं लिया जाना चाहिए। इसके अलावा, वे संभवतः हार्डवेयर प्लेटफॉर्म, लोड आदि पर अत्यधिक निर्भर हैं। हालांकि, परिणामों ने स्पष्ट रूप से प्रदर्शन पर टाइमर त्वरण का प्रभाव दिखाया, यह 2.5-5% है - यह मेरी अपेक्षा से अधिक है। मंदी की डिग्री पारंपरिक दृष्टिकोण पर संदेह करने के लिए पर्याप्त बड़ी है - काउंटर-उत्पादकता में - आवेदन के प्रदर्शन को बढ़ाने के लिए टाइमर की आवृत्ति में वृद्धि।
विंडोज टाइमर की आवृत्ति बढ़ाना कुछ भी अच्छा नहीं है। उसी समय, ऊर्जा बर्बाद हो जाती है और कंप्यूटर धीमा हो जाता है। बिना गतिविधि के घंटों तक लटके सभी अंधाधुंध कार्यक्रमों में इसका उपयोग करने की प्रथा को रोका जाना चाहिए।
यहाँ ग्राफिकल प्रारूप में मेरे परीक्षण कार्यक्रम के परिणाम हैं



बीच में 20 सेकंड की अवधि जहां प्रदर्शन अप्रत्याशित रूप से गिरता है, टाइमर आवृत्ति में वृद्धि के साथ मेल खाता है। मुझे अपने सभी परीक्षणों में समान परिणाम मिले, दोनों बैटरी पावर और मेन पर

स्रोत कोड

चूंकि विज्ञान स्रोत कोड का खुलासा किए बिना नहीं किया जाता है, मैं अपने परीक्षण कार्यक्रम का कोड लाता हूं।

#include “stdafx.h” #include <stdio.h> #include <Windows.h> LARGE_INTEGER g_frequency; const double kDelayTime = 1.0; double GetTime() { LARGE_INTEGER counter; QueryPerformanceCounter(&counter); return counter.QuadPart / double(g_frequency.QuadPart); } int g_array[1024]; int offset; int g_sum; void SpinABit() { for (int i = 0; i < ARRAYSIZE(g_array); ++i) { g_sum += g_array[i + offset]; } } void Stall() { double start = GetTime(); int iterations = 0; for (;;) { ++iterations; SpinABit(); double elapsed = GetTime() – start; if (elapsed >= kDelayTime) { printf(“%1.5e iterations/s\n”, iterations / elapsed); return; } } } int main(int argc, char* argv[]) { QueryPerformanceFrequency(&g_frequency); for (;;) Stall(); return 0; } 

और यहां एक कार्यक्रम है जो टाइमर की आवृत्ति 20 सेकंड तक बढ़ाता है।

 #include <stdio.h> #include <Windows.h> #pragma comment(lib, “winmm.lib”) int main(int argc, char* argv[]) { timeBeginPeriod(1); printf(“Frequency raised.\n”); Sleep(20000); printf(“Frequency lowered.\n”); // timeEndPeriod call is omitted because process // cleanup will do that. return 0; } 

परीक्षण शुरू करने से पहले सिस्टम टाइमर की आवृत्ति की जांच करना याद रखें, अन्यथा आप अंतर नहीं देख सकते हैं।

और फिर अपने कार्यक्रमों के कोड को ठीक करें। सभी एक के रूप में।