क्या स्टॉपवॉच है। गेटिमस्टैम्प कभी रोल हो जाता है? या वापस रोल?

Question

Stopwatch.GetTimestamp() का उपयोग करने में हम पाते हैं कि यदि आप रिटर्न वैल्यू रिकॉर्ड करते हैं और फिर इसे कॉल करना जारी रखते हैं और पिछले रिटर्न वैल्यू की तुलना करते हैं, तो अंत में यह अप्रत्याशित रूप से मूल से कम मान वापस कर देगा।

क्या यह अपेक्षित व्यवहार है?

उत्पादन कोड में ऐसा करने का उद्देश्य एक माइक्रोसेकंद सटीक sytem समय होना है।

तकनीक में डेटटाइम.यूटीसीएनओ को कॉल करना और स्टॉपवॉच.गेटटाइमेस्टैम्प() को क्रमशः मूल UtcNow और originalTimestamp के रूप में कॉल करना शामिल है।

उस बिंदु से आगे, एप्लिकेशन बस Stopwatch.GetTimestamp() को कॉल करता है और स्टॉपवॉच का उपयोग करता है। फ़्रिक्वेंसी यह मूलTimestamp चर से अंतर की गणना करता है और फिर उस मूल को मूल UtcNow में जोड़ता है।

फिर, वोला ... एक कुशल और सटीक माइक्रोसॉन्ड डेटटाइम।

लेकिन, हम पाते हैं कि कभी-कभी Stopwatch.GetTimestamp() कम संख्या वापस आ जाएगा।

यह शायद ही कभी होता है। हमारी सोच यह होती है कि जब ऐसा होता है और जारी रहता है तो बस "रीसेट" करना है।

हालांकि, यह हमें Stopwatch.GetTimestamp() की सटीकता पर संदेह करता है या संदेह है कि नेट लाइब्रेरी में एक बग है।

यदि आप इस पर कुछ प्रकाश डाल सकते हैं, तो कृपया करें।

एफवाईआई, वर्तमान टाइमस्टैम्प मूल्य, आवृत्ति, और लंबे समय के आधार पर। मैक्सवेल्यू यह असंभव प्रतीत होता है कि यह हमारे जीवनकाल के दौरान तब तक रोल हो जाएगा जब तक कि यह हार्डवेयर समस्या न हो।

संपादित करें: हम अब इस मान को "प्रति थ्रेड" की गणना कर रहे हैं और फिर इसे "इसे क्लैंपिंग" कर रहे हैं ताकि कोर को रीसेट करने के लिए कूद के लिए देख सकें।

Answer 1

यह संभव है कि आप समय पर कूद लें क्योंकि आपका धागा कोर कूद रहा है। इस पृष्ठ पर "नोट" देखें: http://msdn.microsoft.com/en-us/library/ebf7z0sw.aspx

Answer 2

स्टॉपवॉच कक्षा का व्यवहार हार्डवेयर समर्थन के आधार पर सिस्टम से सिस्टम में भिन्न होगा।

देखें: http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.ishighresolution.aspx

इसके अलावा, मुझे विश्वास है कि अंतर्निहित बराबर Win32 कॉल (QueryPerformanceCounter) उपयोगी प्रलेखन शामिल हैं: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx

Answer 3

मैं वास्तव में कौन-एक की तरह लगता है पीछे की ओर चला रहे हैं (के बारे में के बारे में पता नहीं है छोटे पीछे की ओर बदलें), लेकिन मैंने अभी तक तीन बार अनुभव किया है कि Stopwatch.GetTimestamp() का मान इतना बड़ा बदल सकता है कि यह ओवरफ्लो अपवाद के बारे में कुछ और गणनाओं में भिन्नता का कारण बनता है इस तरह:
(Stopwatch.GetTimestamp() - ProgramStartStopwatchTimestamp) * n
जहां n कुछ बड़े मूल्य है, लेकिन काफी छोटा है कि अगर स्टॉपवॉच काफी चारों ओर कूद नहीं कर रहे थे, तो कार्यक्रम वर्ष अतिप्रवाह अपवाद बिना चला सकते हैं। ध्यान दें कि कार्यक्रम के शुरू होने के कई घंटे बाद ये अपवाद हुए, इसलिए मुद्दा यह नहीं है कि स्टॉपवॉच शुरू होने के तुरंत बाद थोड़ा सा पीछे चला गया।यह किसी भी दिशा में, पूरी तरह से अलग सीमा तक कूद गया।

स्टॉपवॉच रोलिंग के संबंध में, उपरोक्त मामलों में से एक में (अंतर नहीं, लेकिन स्टॉपवॉच) ने ला 0xFF4 के मूल्य को प्राप्त किया? ???? ???? ????, तो यह एक सीमा तक कूद गया जो रोलिंग के बहुत करीब था। कार्यक्रम को कई बार पुनरारंभ करने के बाद, यह नई श्रृंखला अभी भी प्रभावी रूप से प्रभावी थी। यदि यह किसी भी तरह से कूदने की आवश्यकता पर विचार करने पर विचार करता है ...

यदि यह निर्धारित करने के लिए अतिरिक्त रूप से आवश्यक था कि टाइमस्टैम्प किस कोर पर लिया गया था तो यह शायद मूल संख्या निष्पादित करने में मदद करता है। इस अंत में, GetCurrentProcessorNumber (सर्वर 2003 और Vista के बाद से उपलब्ध) और GetCurrentProcessorNumberEx (सर्वर 2008 आर 2 और विंडोज 7 के बाद से उपलब्ध) नामक फ़ंक्शंस हैं। अधिक विकल्प (विंडोज एक्सपी सहित) के लिए this question's answers भी देखें।
ध्यान दें कि किसी भी समय शेड्यूलर द्वारा कोर नंबर बदला जा सकता है। लेकिन जब कोई स्टॉपवॉच टाइमस्टैंप पढ़ने से पहले कोर नंबर पढ़ता है, और उसके बाद, और कोर नंबर समान रहता है, तो शायद कोई यह मान सकता है कि स्टॉपवॉच रीड भी इस कोर पर किया गया था ...