नैनोसेकंड सटीकता के साथ समय मापन

कुछ महीने पहले मेरे लिए एक ऐतिहासिक पल आया। समय को मापने के लिए मानक ऑपरेटिंग सिस्टम उपकरण मेरे लिए पर्याप्त नहीं हैं। नैनोसेकंड सटीकता और नैनोसेकंड ओवरहेड के साथ मापने में समय लगा।

मैंने एक पुस्तकालय लिखने का फैसला किया जो इस समस्या को हल करेगा। पहली नज़र में, ऐसा लगता था कि ऐसा करने के लिए कुछ खास नहीं था। लेकिन करीबी परीक्षा के दौरान, हमेशा की तरह, यह पता चला कि कई दिलचस्प समस्याएं थीं जिनसे निपटा जाना था। इस लेख में, मैं समस्याओं के बारे में बात करूंगा और उनका समाधान कैसे किया जाएगा।

चूंकि आप कंप्यूटर पर कई अलग-अलग समय को माप सकते हैं, इसलिए मैं तुरंत स्पष्ट कर दूंगा कि यहां हम "स्टॉपवॉच द्वारा समय" के बारे में बात करेंगे। या दीवार-घड़ी का समय। यह वास्तविक समय, बीता हुआ समय आदि है। यही है, एक सरल "मानव" समय, जिसे हम कार्य की शुरुआत में पता लगाते हैं और अंत में रोकते हैं।

माइक्रोसेकंड - लगभग हमेशा के लिए

पिछले कुछ वर्षों में उच्च प्रदर्शन प्रणालियों के डेवलपर्स माइक्रोसेकंड समय के पैमाने के आदी हो गए हैं। माइक्रोसेकंड में, आप एक NVMe ड्राइव से डेटा पढ़ सकते हैं। माइक्रोसेकंड में, डेटा नेटवर्क पर भेजा जा सकता है। सभी के लिए नहीं, बेशक, लेकिन InifiniBand-network के लिए - आसानी से।

इसी समय, माइक्रोसेकंड की भी एक संरचना थी। एक पूर्ण I / O स्टैक में कई सॉफ़्टवेयर और हार्डवेयर घटक होते हैं। उनमें से कुछ द्वारा शुरू की गई देरी उप-माइक्रोसेकंड स्तर पर होती है।

इस परिमाण की देरी को मापने के लिए, माइक्रोसेकंड सटीकता अब पर्याप्त नहीं है। हालांकि, न केवल सटीकता महत्वपूर्ण है, बल्कि समय मापने का ओवरहेड भी है। लिनक्स घड़ी_गेटाइम () सिस्टम कॉल रिटर्न समय नैनोस्कोपिक परिशुद्धता के साथ है। एक मशीन पर जो मेरी उंगलियों (Intel® Xeon® CPU E5-2630 v2 @ 2.60GHz) पर सही है, यह कॉल लगभग 120 ns में पूरी होती है। बहुत अच्छा फिगर। इसके अलावा, clock_gettime () काफी अनुमानित रूप से काम करता है। यह आपको उसकी कॉल के ओवरहेड को ध्यान में रखने की अनुमति देता है और वास्तव में दसियों नैनोसेकंड के क्रम की सटीकता के साथ माप लेता है। हालाँकि, अब हम इस पर ध्यान देते हैं। समय अंतराल को मापने के लिए, आपको दो ऐसे कॉल करने की आवश्यकता है: शुरुआत में और अंत में। यानी 240 एन एस खर्च करते हैं। यदि 1-10 μs के क्रम के घने समय अंतरालों को मापा जाता है, तो ऐसे कुछ मामलों में माप प्रक्रिया स्वयं ही मनाया प्रक्रिया को काफी विकृत कर देगी।

मैंने इस खंड को शुरू किया है कि हाल के वर्षों में IO स्टैक कैसे तेज हुआ है। यह नया है, लेकिन इतनी जल्दी और सही तरीके से समय को मापना चाहते हैं। ऐसी जरूरत हमेशा से रही है। उदाहरण के लिए, हमेशा एक कोड होता था जिसे मैं माइक्रोप्रोसेसर के कम से कम 1 घड़ी चक्र को गति देना चाहता था। या सनसनीखेज स्पेक्टर भेद्यता के बारे में मूल लेख से एक और उदाहरण:



यहां, लाइनें 72-74 एकल मेमोरी एक्सेस ऑपरेशन के निष्पादन समय को मापती हैं। सच है, स्पेक्टर नैनोसेकंड में दिलचस्पी नहीं रखता है। समय को "तोते" में मापा जा सकता है। हम तोते और सेकंड में लौट आएंगे।

समय-स्टाम्प काउंटर

तेज और सटीक समय माप की कुंजी एक विशेष माइक्रोप्रोसेसर काउंटर है। इस काउंटर का मूल्य आमतौर पर एक अलग रजिस्टर में संग्रहीत किया जाता है और आमतौर पर होता है - लेकिन हमेशा नहीं - उपयोगकर्ता स्थान से सुलभ। विभिन्न आर्किटेक्चर पर, काउंटर को अलग तरीके से कहा जाता है:

1. x86 टाइम-स्टैंप काउंटर
2. PowerPC पर समय आधार पंजीयन
3. इटेनियम पर अंतराल समय काउंटर
4. आदि

नीचे मैं हमेशा "टाइम-स्टैंप काउंटर" या TSC नाम का उपयोग करूंगा, हालांकि वास्तव में मैं वास्तुकला की परवाह किए बिना किसी भी ऐसे काउंटर को ध्यान में रखूंगा।

टीएससी मूल्य को आमतौर पर पढ़ना - लेकिन फिर से हमेशा नहीं - एक निर्देश के साथ संभव है। यहाँ x86 के लिए एक उदाहरण है। कड़ाई से बोलते हुए, यह एक शुद्ध कोडांतरक निर्देश नहीं है, लेकिन GNU इनलाइन कोडांतरक:

uint32_t eax, edx; __asm__ __volatile__( "rdtsc" : "=a" (eax), "=d" (edx)); 

Rdtsc इंस्ट्रक्शन में eac और edx रजिस्टरों में TSC रजिस्टर के दो 32-बिट हिस्से हैं। इनमें से, आप एकल 64-बिट मान "गोंद" कर सकते हैं।

एक बार फिर मैं ध्यान देता हूं: यह (और इसी तरह) निर्देशों को ज्यादातर मामलों में सीधे उपयोगकर्ता स्थान से बुलाया जा सकता है। कोई सिस्टम कॉल नहीं करता है। न्यूनतम ओवरहेड।

अब समय मापने के लिए क्या करना होगा?

1. हमारे लिए ब्याज के समय अंतराल की शुरुआत में इस तरह के एक निर्देश को निष्पादित करें। काउंटर वैल्यू याद रखें
2. इस तरह के एक निर्देश को अंत में निष्पादित करें। हम मानते हैं कि पहले निर्देश से दूसरे तक काउंटर का मूल्य बढ़ जाएगा। अन्यथा, इसकी आवश्यकता क्यों है? दूसरा मूल्य याद रखें
3. हम दो संग्रहीत मूल्यों के बीच अंतर पर विचार करते हैं। यह हमारा समय है

यह सरल दिखता है, लेकिन ...

वर्णित प्रक्रिया द्वारा मापा गया समय "तोते" में व्यक्त किया गया है। यह सेकंड में नहीं है। लेकिन कभी-कभी तोते वही होते हैं जिनकी आपको आवश्यकता होती है। ऐसी परिस्थितियां हैं जब समय अंतराल के पूर्ण मूल्य महत्वपूर्ण नहीं हैं, लेकिन विभिन्न अंतराल एक दूसरे से कैसे संबंधित हैं। ऊपर स्पेक्टर उदाहरण बिल्कुल इस स्थिति को दर्शाता है। प्रत्येक व्यक्तिगत मेमोरी एक्सेस की अवधि मायने नहीं रखती है। यह केवल महत्वपूर्ण है कि कुछ पतों पर कॉल दूसरों की तुलना में बहुत तेज़ी से निष्पादित की जाएगी (यह निर्भर करता है कि डेटा कैश या मेमोरी में संग्रहीत है)।

लेकिन क्या होगा अगर तोते की ज़रूरत नहीं है, लेकिन सेकंड / माइक्रोसेकंड / नैनोसेकंड, आदि। दो मूलभूत रूप से अलग-अलग मामलों को यहां प्रतिष्ठित किया जा सकता है:

1. नैनोसेकंड की जरूरत है, लेकिन तब। यही है, पहले तोते में सभी आवश्यक माप करना और उन्हें आगे की प्रक्रिया (उदाहरण के लिए, स्मृति में) के लिए कहीं स्टोर करने की अनुमति है। और माप पूरा होने के बाद ही, एकत्रित तोतों को धीरे-धीरे सेकंड में परिवर्तित करना
2. नैनोसेकंड की जरूरत है "मक्खी पर।" उदाहरण के लिए, आपकी माप प्रक्रिया में किसी प्रकार का "उपभोक्ता" होता है जिसे आप नियंत्रित नहीं करते हैं और जो "मानव" प्रारूप में समय की अपेक्षा करता है

पहला मामला सरल है, दूसरा - संसाधन की आवश्यकता है। रूपांतरण यथासंभव प्रभावी होना चाहिए। यदि यह बहुत सारे संसाधनों का उपभोग करता है, तो यह माप प्रक्रिया को बहुत विकृत कर सकता है। हम नीचे प्रभावी रूपांतरण के बारे में बात करेंगे। यहां हमने अब तक इस समस्या की पहचान की है और दूसरे पर आगे बढ़ते हैं।

टाइम-स्टैंप काउंटर उतने सरल नहीं हैं जितने हम चाहेंगे। कुछ आर्किटेक्चर पर:

1. यह गारंटी नहीं है कि TSC उच्च आवृत्ति पर अपडेट किया गया है। यदि टीएससी को अपडेट किया जाता है, तो कहें, एक बार प्रत्येक माइक्रोसेकंड, फिर इसके साथ नैनोसेकंड को ठीक करना संभव नहीं होगा।
2. आवृत्ति जिसके साथ TSC अपडेट किया जाता है, समय के साथ भिन्न हो सकती है
3. सिस्टम में मौजूद विभिन्न सीपीयू पर, TSCs को विभिन्न आवृत्तियों पर अपडेट किया जा सकता है
4. टीएससी के बीच अलग-अलग सीपीयू पर टिक करने के लिए एक बदलाव हो सकता है

यहाँ एक उदाहरण है जो पिछली समस्या को दर्शाता है। मान लें कि हमारे पास दो CPU: CPU1 और CPU2 के साथ एक प्रणाली है। मान लीजिए कि पहले सीपीयू पर टीएससी टिकों की संख्या से दूसरे से पीछे है, जो 5 सेकंड के बराबर है। आगे मान लीजिए कि गणना के समय को मापने वाले सिस्टम में एक धारा शुरू की जाती है, जो वह खुद करता है। ऐसा करने के लिए, स्ट्रीम पहले टीएससी मान पढ़ता है, फिर गणना करता है, और फिर दूसरा टीएससी मान पढ़ता है। यदि इसके पूरे जीवन के दौरान एक धागा केवल किसी एक सीपीयू पर रहता है - तो कोई समस्या नहीं है। लेकिन क्या होगा अगर धागा सीपीयू 1 पर शुरू होता है, वहां पहले टीएससी मूल्य को मापा जाता है, और फिर गणनाओं के बीच में ऑपरेटिंग सिस्टम द्वारा सीपीयू 2 में ले जाया जाता है, जहां यह दूसरा टीएससी मूल्य पढ़ता है? इस मामले में, गणना वे वास्तव में कर रहे हैं की तुलना में 5 सेकंड लंबा लगेगा।

ऊपर सूचीबद्ध समस्याओं के कारण, टीएससी कुछ प्रणालियों पर समय के एक विश्वसनीय स्रोत के रूप में काम नहीं कर सकता है। हालांकि, समान समस्याओं से "पीड़ित" अन्य प्रणालियों पर, टीएससी का उपयोग अभी भी किया जा सकता है। यह विशेष वास्तु सुविधाओं के लिए संभव बनाया गया है:

1. उपकरण हर बार एक विशेष व्यवधान उत्पन्न कर सकता है जिसके साथ TSC अपडेट किया जाता है। इसी समय, उपकरण वर्तमान आवृत्ति का पता लगाने का अवसर भी प्रदान करता है। वैकल्पिक रूप से, टीएससी रिफ्रेश रेट को ऑपरेटिंग सिस्टम के नियंत्रण में रखा जा सकता है (देखें "पावर आईएसए संस्करण 2.06 संशोधन बी, बुक II, अध्याय 5")
2. टीएससी मूल्य के साथ, उपकरण सीपीयू की आईडी भी प्रदान कर सकता है, जिस पर यह मूल्य पढ़ा जाता है (इंटेल आरडीटीएससीपी निर्देश देखें, "इंटेल 64 और आईए -32 आर्किटेक्चर सॉफ्टवेयर डेवलपर मैनुअल, वॉल्यूम 2)
3. कुछ प्रणालियों पर, आप प्रत्येक CPU के लिए TSC मान को प्रोग्रामेटिक रूप से समायोजित कर सकते हैं (Intel WRMSR निर्देश देखें और IA32_TIME_STAMP_COUNTER, "Intel 64 और IA-32 आर्किटेक्चर सॉफ्टवेयर डेवलपर का मैनुअल", खंड 3 को पंजीकृत करें)

सामान्य तौर पर, विभिन्न आर्किटेक्चर पर समय मीटर को कैसे लागू किया जाता है, इसका विषय आकर्षक और व्यापक है। यदि आपके पास समय और रुचि है, तो मैं डाइविंग की सलाह देता हूं। उदाहरण के लिए, आप सीखेंगे कि उदाहरण के लिए, कुछ प्रणालियाँ आपको यह निर्धारित करने की अनुमति देती हैं कि क्या TSC समय के विश्वसनीय स्रोत के रूप में काम कर सकता है।

तो, टीएससी के कई वास्तुशिल्प कार्यान्वयन हैं, प्रत्येक की अपनी विशेषताओं के साथ है। लेकिन यह दिलचस्प है कि इस सभी चिड़ियाघर में एक सामान्य प्रवृत्ति स्थापित की गई है। आधुनिक हार्डवेयर और ऑपरेटिंग सिस्टम यह सुनिश्चित करने का प्रयास करते हैं :

1. TSC सिस्टम में प्रत्येक CPU पर समान आवृत्ति पर टिक करता है
2. यह आवृत्ति समय में नहीं बदलती है
3. टीएससी के बीच अलग-अलग सीपीयू पर टिक करने के लिए कोई बदलाव नहीं है

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

पुस्तकालय

मैंने अलग-अलग आर्किटेक्चर के झुंड के हार्डवेयर चिप्स पर रखना शुरू नहीं किया। इसके बजाय, मैंने फैसला किया कि मेरी लाइब्रेरी ट्रेंड-ओरिएंटेड होगी। उसका विशुद्ध रूप से अनुभवजन्य ध्यान है:

1. यह आपको एक समय स्रोत के रूप में टीएससी की विश्वसनीयता को प्रयोगात्मक रूप से सत्यापित करने की अनुमति देता है
2. आपको प्रायोगिक रूप से टिकों को नैनोसेकंड में बदलने के लिए आवश्यक प्रायोगिक गणना करने की अनुमति देता है
3. स्वाभाविक रूप से, लाइब्रेरी TSC को पढ़ने और नैनोस्कॉन्ड्स को "फ्लाई पर" में टिक बदलने के लिए सुविधाजनक इंटरफेस प्रदान करती है।

लाइब्रेरी कोड यहां उपलब्ध है। यह केवल लिनक्स पर संकलित और निष्पादित किया जाएगा।

कोड में, आप सभी तरीकों के कार्यान्वयन का विवरण देख सकते हैं, जिस पर बाद में चर्चा की जाएगी।

TSC विश्वसनीयता मूल्यांकन

पुस्तकालय एक इंटरफ़ेस प्रदान करता है जो दो रेटिंग देता है:

1. विभिन्न सीपीयू से संबंधित काउंटरों के बीच अधिकतम बदलाव। प्रक्रिया के लिए उपलब्ध केवल सीपीयू पर विचार किया जाता है। उदाहरण के लिए, यदि किसी प्रक्रिया में तीन सीपीयू उपलब्ध हैं, और उसी समय इन सीपीयू पर टीएससी 50, 150, 20 है, तो अधिकतम बदलाव 150-20 = 130 होगा। स्वाभाविक रूप से, पुस्तकालय प्रयोगात्मक रूप से वास्तविक अधिकतम बदलाव प्राप्त करने में सक्षम नहीं होगा, लेकिन यह एक अनुमान देगा जिसमें यह बदलाव फिट होगा। आकलन के साथ आगे क्या करना है? कैसे करें इस्तेमाल? यह पहले से ही क्लाइंट कोड को हल करता है। लेकिन अर्थ लगभग निम्नलिखित है। अधिकतम पारी वह अधिकतम मूल्य है जिसके द्वारा ग्राहक कोड बनाने वाला आयाम विकृत हो सकता है। मान लीजिए, तीन सीपीयू के साथ हमारे उदाहरण में, क्लाइंट कोड सीपीयू 3 (जहां टीएससी 20 था) पर समय को मापना शुरू किया, और सीपीयू 2 (जहां टीएससी 150 था) पर समाप्त हो गया। यह पता चला है कि एक अतिरिक्त 130 टिकें मापा अंतराल में रेंगना होगा। और फिर कभी नहीं। CPU1 और CPU2 के बीच का अंतर केवल 100 टिक होगा। 130 टिकों का अनुमान होने के कारण (वास्तव में, यह बहुत अधिक रूढ़िवादी होगा), ग्राहक यह तय कर सकता है कि क्या इस तरह का विरूपण मूल्य उसे सूट करता है या नहीं
2. टीएससी मूल्यों को एक ही या अलग-अलग सीपीयू वृद्धि पर क्रमिक रूप से मापा जाता है। यहाँ विचार है। मान लीजिए कि हमारे पास कई सीपीयू हैं। मान लें कि उनकी घड़ी सिंक्रनाइज़ है और एक ही आवृत्ति पर टिक रही है। फिर यदि आप पहली बार एक सीपीयू पर समय को मापते हैं, और फिर इसे फिर से मापते हैं - पहले से ही उपलब्ध सीपीयू में से - तो दूसरा अंक पहले से बड़ा होना चाहिए।
   
   मैं इस अनुमान को टीएससी एकरसता अनुमान से नीचे कहूंगा
   

अब देखते हैं कि हम पहला अनुमान कैसे प्राप्त कर सकते हैं:

1. प्रक्रिया के लिए उपलब्ध प्रोसेसर में से एक "बुनियादी" घोषित किया गया है
2. तब सभी अन्य सीपीयू को क्रमबद्ध किया जाता है, और उनमें से प्रत्येक के लिए पारी की गणना की जाती है: TSC___CPU – TSC___CPU । यह निम्नानुसार किया जाता है:
   
   • क) तीन मापा मूल्यों को क्रमिक रूप से लिया जाता है (एक के बाद एक!): TSC_base_1, TSC_current, TSC_base_2 । यहां, वर्तमान इंगित करता है कि मूल्य वर्तमान सीपीयू पर मापा गया था, और आधार पर आधार
   • b) शिफ्ट TSC___CPU – TSC___CPU अंतराल [TSC_current – TSC_base_2, TSC_current – TSC_base_1] में झूठ होना चाहिए। यह इस धारणा के तहत है कि TSCs दोनों CPU पर समान आवृत्ति पर टिक कर रहे हैं।
   • c) चरण a) -b) को कई बार दोहराया जाता है। चरण बी में प्राप्त सभी अंतरालों के अंतर की गणना की जाती है। परिणामी अंतराल को TSC___CPU – TSC___CPU शिफ्ट के अनुमान के रूप में लिया जाता है
   
   
3. आधार के सापेक्ष प्रत्येक सीपीयू के लिए एक शिफ्ट अनुमान प्राप्त होने के बाद, सभी उपलब्ध सीपीयू के बीच अधिकतम बदलाव का अनुमान प्राप्त करना आसान है:
   
   • a) न्यूनतम अंतराल की गणना की जाती है, जिसमें चरण 2 में प्राप्त सभी परिणामी अंतराल शामिल हैं
   • ख) इस अंतराल की चौड़ाई को अलग-अलग सीपीयू पर टिक टीएससी के बीच अधिकतम बदलाव के अनुमान के रूप में लिया जाता है
   
   

पुस्तकालय में एकरसता का मूल्यांकन करने के लिए, निम्नलिखित एल्गोरिथ्म को लागू किया गया है:

1. मान लीजिए कि एक प्रक्रिया में एन सीपीयू उपलब्ध है
2. CPU1 पर TSC को मापना
3. सीपीसी 2 पर टीएससी को मापने
4. ...
5. CPUN पर TSC को मापना
6. सीपीसी 1 पर फिर से टीएससी को मापें
7. हम सत्यापित करते हैं कि पहले से आखिरी तक मापे गए मान एक-दूसरे से बहुत अधिक बढ़े हैं

यहां यह महत्वपूर्ण है कि पहला और अंतिम मान एक ही सीपीयू पर मापा जाए। और यहाँ क्यों है। मान लीजिए कि हमारे पास 3 सीपीयू हैं। मान लीजिए कि CPU2 पर TSC को CPU1 पर TSC के सापेक्ष +100 टिक्स द्वारा स्थानांतरित किया गया है। यह भी मान लें कि CPU3 पर TSC को CPU2 पर TSC के सापेक्ष +100 टिक्स द्वारा स्थानांतरित किया गया है। घटनाओं की निम्नलिखित श्रृंखला पर विचार करें:

• सीपीसी 1 पर टीएससी पढ़ें। मान 10 प्राप्त करें
• 2 टिक गए
• सीपीसी 2 पर टीएससी पढ़ें। 112 होना चाहिए
• 2 टिक गए
• सीपीसी 3 पर टीएससी पढ़ें। 214 होना चाहिए

अब तक, घड़ी सिंक्रनाइज़ दिखाई देती है। लेकिन चलो फिर से CPU1 पर TSC को मापें:

• 2 टिक गए
• सीपीसी 1 पर टीएससी पढ़ें। 16 होनी चाहिए

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

• अधिकतम बदलाव का अनुमान कम है
• एकरसता के मूल्यांकन में अधिक विश्वास

अगले भाग में, हम तंग माप लेने के बारे में बात करेंगे। मैं यहाँ जोड़ना चाहूँगा कि TSC विश्वसनीयता अनुमानों की गणना करते समय, पुस्तकालय उदाहरण के लिए कई और सरल "जूँ" चेक करता है:

• सीमित सत्यापन कि विभिन्न सीपीयू पर टीएससी एक ही गति से टिक कर रहे हैं
• यह जांचना कि काउंटर वास्तव में समय के साथ बदलते हैं, और न केवल समान मूल्य दिखाते हैं

काउंटर मान एकत्र करने के लिए दो तरीके

पुस्तकालय में, मैंने टीएससी मूल्यों को एकत्र करने के लिए दो तरीके लागू किए:

1. सीपीयू के बीच स्विच करें । इस पद्धति में, टीएससी की विश्वसनीयता का आकलन करने के लिए आवश्यक सभी डेटा को एक एकल थ्रेड द्वारा एकत्रित किया जाता है जो एक सीपीयू से दूसरे में "कूदता है"। पिछले अनुभाग में वर्णित दोनों एल्गोरिदम इस पद्धति के लिए उपयुक्त हैं और दूसरे के लिए उपयुक्त नहीं हैं।
   "सीपीयू के बीच स्विच करना" का कोई व्यावहारिक उपयोग नहीं है। विधि "चारों ओर खेल" के लिए लागू की गई थी। विधि के साथ समस्या यह है कि एक सीपीयू से दूसरे में एक धारा को "खींचें" करने के लिए आवश्यक समय बहुत बड़ा है। तदनुसार, लगातार टीएससी माप के बीच बहुत समय गुजरता है, और अनुमानों की सटीकता बहुत कम है। उदाहरण के लिए, टीएससी के बीच अधिकतम बदलाव के लिए एक विशिष्ट अनुमान 23,000 टिक के क्षेत्र में प्राप्त किया जाता है।
   
   हालाँकि, विधि के कुछ फायदे हैं:
   
   • यह बिल्कुल निर्धारक है। यदि आपको CPU1, CPU2, CPU3 पर क्रमिक रूप से TSC को मापने की आवश्यकता है, तो हम इसे लेते हैं और इसे करते हैं: CPU1 पर स्विच करें, TSC पढ़ें, CPU2 पर जाएँ, TSC पढ़ें, और अंत में, CPU3 पर जाएँ, TSC पढ़ें
   • संभवतः, यदि सिस्टम में सीपीयू की संख्या बहुत तेजी से बढ़ती है, तो उनके बीच स्विचिंग समय बहुत अधिक धीरे-धीरे बढ़ना चाहिए। इसलिए, सिद्धांत रूप में, जाहिरा तौर पर, एक प्रणाली मौजूद हो सकती है - एक बहुत बड़ी प्रणाली! - जिसमें विधि का उपयोग उचित होगा। लेकिन फिर भी यह संभावना नहीं है
   
   
2. कैस का उपयोग करके माप का आदेश दिया गया । इस पद्धति में, डेटा को कई थ्रेड द्वारा समानांतर में एकत्रित किया जाता है। प्रत्येक उपलब्ध सीपीयू एक धागा शुरू करता है। विभिन्न थ्रेड्स द्वारा किए गए मापों को "तुलना-और-स्वैप" ऑपरेशन का उपयोग करके एक ही क्रम में व्यवस्थित किया जाता है। नीचे एक कोड है जो दिखाता है कि यह कैसे किया जाता है।
   विधि का विचार फियो से उधार लिया गया है, I / O भार उत्पन्न करने के लिए एक लोकप्रिय उपकरण।
   
   इस पद्धति की शक्ति के साथ प्राप्त विश्वसनीयता का अनुमान पहले से ही काफी अच्छा लग रहा है। उदाहरण के लिए, अधिकतम बदलाव का एक अनुमान पहले से ही कई सौ टिक्स के स्तर पर प्राप्त किया गया है। एकरसता का एक चेक आपको सैकड़ों टिक के भीतर सिंक से घड़ी को पकड़ने की अनुमति देता है।
   
   हालांकि, पिछले अनुभाग में दिए गए एल्गोरिदम इस पद्धति के लिए उपयुक्त नहीं हैं। उनके लिए यह महत्वपूर्ण है कि TSC मानों को पूर्व निर्धारित क्रम में मापा जाए। “CAS द्वारा आदेशित माप” की विधि इसकी अनुमति नहीं देती है। इसके बजाय, पहले यादृच्छिक माप का एक लंबा अनुक्रम एकत्र किया जाता है, और फिर एल्गोरिदम (पहले से अलग) इस क्रम में "उपयुक्त" सीपीयू पर पढ़े गए मूल्यों को खोजने की कोशिश करते हैं।
   
   मैं इन एल्गोरिदम को यहां नहीं दूंगा, ताकि आपके ध्यान का दुरुपयोग न हो। आप उन्हें कोड में देख सकते हैं। कई टिप्पणियाँ हैं। सिद्धांत रूप में, ये एल्गोरिदम समान हैं। मौलिक रूप से नए बिंदु का सत्यापन है कि कैसे यादृच्छिक रूप से टाइप किए गए TSC क्रम सांख्यिकीय रूप से "गुणात्मक" होते हैं। टीएससी विश्वसनीयता अनुमानों के लिए सांख्यिकीय महत्व का न्यूनतम स्वीकार्य स्तर निर्धारित करना भी संभव है।
   
   सैद्धांतिक रूप से, बहुत बड़े सिस्टम पर, "कैस ऑर्डर किया गया" विधि खराब परिणाम दे सकती है। विधि को एक सामान्य मेमोरी लोकेशन तक पहुंचने के लिए प्रोसेसर की आवश्यकता होती है। यदि बहुत सारे प्रोसेसर हैं, तो प्रतियोगिता बहुत तीव्र हो सकती है। नतीजतन, अच्छे सांख्यिकीय गुणों के साथ माप अनुक्रम बनाना मुश्किल होगा। हालांकि, फिलहाल, यह स्थिति संभावना नहीं है।
   

मैंने कुछ कोड का वादा किया था। यहां बताया गया है कि कैस का उपयोग करके एकल श्रृंखला में माप का निर्माण करना कैसा दिखता है।

  for ( uint64_t i = 0; i < arg->probes_count; i++ ) { uint64_t seq_num = 0; uint64_t tsc_val = 0; do { __atomic_load( seq_counter, &seq_num, __ATOMIC_ACQUIRE); __sync_synchronize(); tsc_val = WTMLIB_GET_TSC(); } while ( !__atomic_compare_exchange_n( seq_counter, &seq_num, seq_num + 1, false, __ATOMIC_ACQ_REL, __ATOMIC_RELAXED)); arg->tsc_probes[i].seq_num = seq_num; arg->tsc_probes[i].tsc_val = tsc_val; } 

यह कोड हर उपलब्ध सीपीयू पर निष्पादित किया जाता है। सभी थ्रेड्स में साझा चर seq_counter । टीएससी पढ़ने से पहले, धारा इस चर का मूल्य पढ़ती है और इसे चर seq_num में संग्रहीत seq_num । फिर TSC पढ़ता है। फिर यह एक-एक करके seq_counter को परमाणु रूप से बढ़ाने की कोशिश करता है, लेकिन केवल तब ही जब चर को पढ़ा नहीं गया है। यदि ऑपरेशन सफल होता है, तो इसका मतलब यह है कि थ्रेड मापा TSC मान के पीछे seq_num में संग्रहीत अनुक्रम संख्या "दांव" में seq_num रहा। अगला सीरियल नंबर, जो कि हिस्सेदारी में सक्षम होगा (संभवतः पहले से ही दूसरे धागे में) एक और होगा। इस नंबर के लिए seq_counter वैरिएबल से लिया गया है, और __atomic_compare_exchange_n() प्रत्येक सफल कॉल से इस वैरिएबल में एक वृद्धि होती है।


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

मक्खी पर टिको को नैनोसेकंड में बदलें

टीएससी की विश्वसनीयता की जांच करने के बाद, लाइब्रेरी का दूसरा प्रमुख उद्देश्य टिकों को मक्खी पर नैनोसेकंड में परिवर्तित करना है। मैंने इस रूपांतरण का विचार पहले से उल्लेख किए गए फियो से लिया था। हालाँकि, मुझे कुछ महत्वपूर्ण सुधार करने पड़े, क्योंकि जैसा कि मेरे विश्लेषण से पता चला है, फियो में ही रूपांतरण प्रक्रिया पर्याप्त रूप से काम नहीं करती है। वहां आपको कम सटीकता मिलती है।

मैं एक उदाहरण के साथ शुरुआत करूंगा।

आदर्श रूप में, मैं इस तरह से नैनो सेकेंड में टिक बदलना चाहूंगा:
ns_time = tsc_ticks / tsc_per_ns
हम चाहते हैं कि रूपांतरण पर खर्च होने वाला समय कम से कम हो। इसलिए, हम विशेष रूप से पूर्णांक अंकगणित का उपयोग करने का लक्ष्य रखते हैं। आइए देखें कि यह हमें किस तरह से खतरे में डाल सकता है।

यदि tsc_per_ns = 3 , तो सटीकता के दृष्टिकोण से एक साधारण पूर्णांक विभाजन, ठीक काम करता है: ns_time = tsc_ticks / 3 ।

लेकिन क्या अगर tsc_per_ns = 3.333 ?यदि यह संख्या 3 से गोल है, तो रूपांतरण सटीकता बहुत कम होगी। इस प्रकार इस समस्या को दूर करने के लिए:
ns_time = (tsc_ticks * factor) / (3.333 * factor)।

यदि कारक factorपर्याप्त बड़ा है, तो सटीकता अच्छी होगी। लेकिन कुछ बुरा रहेगा। अर्थात्, ओवरहेड रूपांतरण। इंटीजर डिवीजन बहुत महंगा ऑपरेशन है। उदाहरण के लिए, x86 पर इसे 10+ घड़ी चक्र की आवश्यकता होती है। इसके अलावा, पूर्णांक विभाजन संचालन हमेशा पाइपलाइन नहीं किया जाता है।

हम बराबर के रूप में हमारे सूत्र को फिर से लिखने
ns_time = (tsc_ticks * factor / 3.333) / factor।

पहला विभाजन कोई समस्या नहीं है। हम पहले से गणना कर सकते हैं (factor / 3.333)। लेकिन दूसरा विभाजन अभी भी दर्द है। उससे छुटकारा पाने के लिए, आइए चुनते हैंfactorदो की शक्ति के बराबर। उसके बाद, एक सरल और तेज ऑपरेशन - दूसरे डिवीजन को थोड़ा बदलाव से बदला जा सकता है।

आप कितना बड़ा चुन सकते हैं factor? दुर्भाग्य से, factorयह मनमाने ढंग से बड़ा नहीं हो सकता। यह इस स्थिति से सीमित है कि अंश में गुणा 64-बिट प्रकार के अतिप्रवाह के लिए नहीं होना चाहिए। हां, हम केवल "देशी" प्रकारों का उपयोग करना चाहते हैं। फिर से, रूपांतरण ओवरहेड्स को न्यूनतम रखने के लिए।

अब देखते हैं कि यह factorहमारे विशिष्ट उदाहरण में कितना बड़ा हो सकता है । मान लीजिए हम एक वर्ष तक के समय अंतराल के साथ काम करना चाहते हैं। वर्ष के दौरान टीएससी निम्नलिखित समय tiknet: 3.333 * 1000000000 * 60 * 60 * 24 * 365 = 105109488000000000। विभाजित 64-बिट प्रकार संख्या की एक अधिकतम मूल्य है: 18446744073709551615 / 105109488000000000 ~ 175.5। तो अभिव्यक्ति(factor / 3.333)इस मान से अधिक नहीं होना चाहिए। तो फिर हमारे पास factor <= 175.5 * 3.333 ~ 584.9। दो की सबसे बड़ी शक्ति जो इस संख्या से अधिक नहीं है 512 है। इसलिए, हमारे रूपांतरण सूत्र का रूप लेता है:

ns_time = (tsc_ticks * 512 / 3.333) / 512

या:

ns_time = tsc_ticks * 153 / 512

ठीक है। आइए अब देखें कि इस सूत्र में सटीकता के साथ क्या है। एक वर्ष में 1000000000 * 60 * 60 * 24 * 365 = 31536000000000000नैनोसेकंड होता है। हमारे सूत्र देता है: 105109488000000000 * 153 / 512 = 31409671218750000। वर्तमान मूल्य के साथ अंतर 126328781250000 नैनोसेकंड या 126328781250000 / 1000000000 / 60 / 60 ~ 35घंटे है।

यह एक बड़ी गलती है। हम बेहतर सटीकता चाहते हैं। क्या होगा अगर हम एक घंटे से अधिक समय के अंतराल को मापें? मैं गणनाओं को छोड़ दूंगा। वे सिर्फ किए गए लोगों के लिए पूरी तरह से समान हैं। अंतिम सूत्र होगा:

ns_time = tsc_ticks * 1258417 / 4194304(1)

रूपांतरण त्रुटि प्रति घंटे केवल 119,305 नैनोसेकंड (जो 0.2 मिलीसेकंड से कम है) होगी। बहुत, बहुत अच्छा। यदि अधिकतम परिवर्तनीय मूल्य एक घंटे से भी कम है, तो सटीकता भी बेहतर होगी। लेकिन हम इसका उपयोग कैसे करते हैं? समय माप को एक घंटे तक सीमित न करें?

आइए हम निम्नलिखित क्षण पर ध्यान दें:

tsc_ticks = (tsc_ticks_per_1_hour * number_of_hours) + tsc_ticks_remainder

यदि हम गणना करते हैं tsc_ticks_per_1_hour, तो हम इसमें number_of_hoursसे निकाल सकते हैं tsc_ticks। इसके बाद, हम जानते हैं कि एक घंटे में कितने नैनोसेकंड निहित हैं। इसलिए, हमारे लिए नैनोसेकंड में उस हिस्से का अनुवाद करना मुश्किल नहीं होगा tsc_ticksजो पूरे घंटे के लिए मेल खाता है। रूपांतरण को पूरा करने के लिए, हमें नैनोसेकंड में अनुवाद करना होगाtsc_ticks_remainder। हालांकि, हम जानते हैं कि यह संख्या एक घंटे से भी कम समय में आई। तो, इसे नैनोसेकंड में बदलने के लिए, हम सूत्र (1) का उपयोग कर सकते हैं।

हो गया। ऐसा रूपांतरण तंत्र हमें सूट करता है। आइए अब इसे संक्षिप्त और अनुकूलित करते हैं।

सबसे पहले, हम रूपांतरण त्रुटियों पर लचीला नियंत्रण रखना चाहते हैं। हम रूपांतरण पैरामीटर को 1 घंटे के समय अंतराल में बांधना नहीं चाहते हैं। इसे एक मनमाना समय अंतराल होने दें:

tsc_ticks = modulus * number_of_moduli_periods + tsc_ticks_remainder

एक बार फिर, याद रखें कि शेष को नैनोसेकंड में कैसे परिवर्तित किया जाए:

ns_per_remainder = (tsc_ticks_remainder * factor / tsc_per_nsec) / factor

हम रूपांतरण मापदंडों की गणना करते हैं (हम जानते हैं कि tsc_ticks_remainder < modulus):

modulus * (factor / tsc_per_nsec) <= UINT64_MAX
factor <= (UINT64_MAX / modulus) * tsc_per_nsec
2 ^ shift <= (UINT64_MAX / modulus) * tsc_per_nsec


थकाऊपन के लिए, यह ध्यान दिया जाना चाहिए कि अंतिम असमानता पूर्णांक अंकगणित के ढांचे में पहले के बराबर नहीं है। लेकिन मैं लंबे समय तक इस पर ध्यान नहीं दूंगा। मैं केवल यह कह सकता हूं कि अंतिम असमानता पहले की तुलना में अधिक गंभीर है, और इसलिए उपयोग करने के लिए सुरक्षित है।

अंतिम असमानता से प्राप्त करने के बाद shift, हम गणना करते हैं: और फिर इन मापदंडों का उपयोग शेष को नैनोसेकंड में परिवर्तित करने के लिए किया जाता है: इसलिए, हमने शेष रूपांतरण का पता लगा लिया। अगले समस्या को हल किया जा करने के लिए - के हटाने है और से । हमेशा की तरह, हम इसे तेजी से करना चाहते हैं। हमेशा की तरह, हम विभाजन का उपयोग नहीं करना चाहते हैं। इसलिए, हम केवल दो की शक्ति के बराबर चुनते हैं : फिर:

factor = 2 ^ shift
mult = factor / tsc_per_nsec




ns_per_remainder = (tsc_ticks_remainder * mult) >> shift


tsc_ticks_remaindernumber_of_moduli_periodstsc_ticksmodulus

modulus = 2 ^ remainder_bit_length



number_of_moduli_periods = tsc_ticks >> remainder_bit_length
tsc_ticks_remainder = tsc_ticks & (modulus - 1)

बहुत बढ़िया।अब हम जानते हैं कि कैसे tsc_ticks number_of_moduli_periodsऔर से निकालने के लिए tsc_ticks_remainder। और हम जानते हैं कि tsc_ticks_remainderनैनोसेकंड में कैसे परिवर्तित किया जाए। यह समझना बाकी है कि टिक के उस हिस्से को कैसे परिवर्तित किया जाए, जो कि एक बहु है, नैनोसेकंड में modulus। लेकिन सब कुछ सरल है:

ns_per_moduli = ns_per_modulus * number_of_moduli_periods

ns_per_modulusआप अग्रिम में गणना कर सकते हैं। इसके अलावा, उसी सूत्र के अनुसार जिसके द्वारा हम शेष को परिवर्तित करते हैं। इस सूत्र का उपयोग उन अवधियों के लिए किया जा सकता है, जो अब नहीं हैं modulus। खुद modulus, ज़ाहिर है, अब से नहीं modulus।

ns_per_modulus = (modulus * mult) >> shift

वह सब है! हम टिकों को नैनोकैन्ड्स पर मक्खी में बदलने के लिए आवश्यक सभी मापदंडों की गणना करने में सक्षम थे। अब संक्षेप में रूपांतरण प्रक्रिया को प्रस्तुत करें:

1. हमारे पास है tsc_ticks
2. number_of_moduli_periods = tsc_ticks >> remainder_bit_length
3. tsc_ticks_remainder = tsc_ticks & (modulus - 1)
4. ns = ns_per_modulus * number_of_moduli_periods + (tsc_ticks_remainder * mult) >> shift

इस प्रक्रिया, मानकों में remainder_bit_length, modulus, ns_per_modulus, multऔर shiftprecalculation अग्रिम।

यदि आप अभी भी इस पोस्ट को पढ़ रहे हैं, तो आप महान या महान हैं। यह भी संभव है कि आप एक प्रदर्शन विश्लेषक या उच्च-प्रदर्शन सॉफ़्टवेयर के डेवलपर हों।

तो यहाँ है।यह पता चला है कि हम अभी तक समाप्त नहीं हुए हैं :)

याद रखें कि हमने पैरामीटर की गणना कैसे की mult? यह इस प्रकार था:

mult = factor / tsc_per_nsec

प्रश्न: यह कहां से आता है tsc_per_nsec?
एक नैनोसेकंड में टिक्स की संख्या बहुत कम मूल्य है। वास्तव में, इसके बजाय मेरी लाइब्रेरी का tsc_per_nsecउपयोग किया जाता है (tsc_per_sec / 1000000000)। यह है:

mult = factor * 1000000000 / tsc_per_sec

और दो दिलचस्प सवाल हैं:

1. उदाहरण के लिए tsc_per_sec, क्यों और क्यों नहीं tsc_per_msec?
2. ये कहां से लाएं tsc_per_sec?

पहले एक के साथ शुरू करते हैं। फियो अब वास्तव में प्रति मिलीसेकंड की संख्या का उपयोग करता है। और उस के साथ समस्याएं हैं। मशीन पर, मानकों, जिनमें से मैं ऊपर नाम tsc_per_msec = 2599998। जबकि tsc_per_sec = 2599998971। अगर हम इन नंबरों को एक पैमाने पर लाते हैं, तो उनका अनुपात एकता के बहुत करीब होगा: 0.999999626 लेकिन अगर हम पहले का उपयोग करते हैं, और दूसरे का नहीं, तो हर दूसरे के लिए हमारे पास 374 नैनोसेकंड त्रुटि होगी। तो - tsc_per_sec।

आगे ... कैसे गिनें tsc_per_sec?

यह प्रत्यक्ष माप के आधार पर किया जाता है: "कुछ समय" एक विन्यास योग्य पैरामीटर है। यह बड़ा, छोटा या एक सेकंड के बराबर हो सकता है। मान लीजिए कि यह आधा सेकंड है। आगे मान लें कि बीच में वास्तविक अंतर और 0.6 सेकंड के लिए निकला। तब ।

start_sytem_time = clock_gettime()
start_tsc = WTMLIB_GET_TSC()
-
end_system_time = clock_gettime()
end_tsc = WTMLIB_GET_TSC()


end_system_timestart_system_timetsc_per_sec = (end_tsc – start_tsc) / 0,6

पुस्तकालय इस तरह से कई मूल्यों पर विचार करता है tsc_per_sec। और फिर, मानक तरीकों का उपयोग करते हुए, यह सांख्यिकीय शोर के "उन्हें" साफ करता है और एक एकल मूल्य प्राप्त करता है जिस पर tsc_per_secभरोसा किया जा सकता है।

ऊपर दिए गए समय माप आरेख में, कॉल का क्रम clock_gettime()और महत्वपूर्ण है WTMLIB_GET_TSC()। यह महत्वपूर्ण है WTMLIB_GET_TSC()कि एक ही समय दो कॉलों के बीच में दो कॉलों के बीच समाप्त हो जाए clock_gettime()। फिर टीएससी टिक के साथ सिस्टम समय को आसानी से सहसंबंधित करना संभव होगा। और फिर मूल्यों का बिखराव tsc_per_secवास्तव में यादृच्छिक माना जा सकता है। इस माप योजना के साथ, मान tsc_per_secसमान संभावना के साथ किसी भी दिशा में औसत मूल्य से विचलित हो जाएगा। और उनके लिए मानक फ़िल्टरिंग विधियों को लागू करना संभव होगा।

निष्कर्ष

शायद बस इतना ही।

लेकिन प्रभावी समय मापन का विषय यहीं तक सीमित नहीं है। कई बारीकियां हैं। रुचि रखने वालों के लिए, मैं निम्नलिखित मुद्दों पर स्वतंत्र रूप से काम करने का प्रस्ताव देता हूं:

• संचय पर या तो - या तो कैश में रूपांतरण मापदंडों को संग्रहीत करना
• किन सीमाओं को कम किया जा सकता है modulus(जिससे रूपांतरण की सटीकता बढ़ रही है)?
• जैसा कि हमने देखा है, रूपांतरण सटीकता न केवल प्रभावित होती है modulus, बल्कि समय अंतराल के आकार से भी प्रभावित होती है, जो टिक्स ( tsc_per_msecया tsc_per_sec) के साथ संबंध रखती है । दोनों कारकों के प्रभाव को कैसे संतुलित करें?
• वर्चुअल मशीन में टी.एस.सी. क्या मैं इसका उपयोग कर सकता हूं?
• . , fio timespec. :
  
  tp->tv_sec = nsecs / 1000000000ULL;
  
  , TSC . , ,
  

इस लेख में जिन विधियों पर चर्चा की गई है, वे हमें कई दसियों नैनोसेकंड के क्रम की सटीकता के साथ एक सेकंड के समय के पैमाने को मापने की अनुमति देते हैं। यह वह सटीकता है जो मैं अपने पुस्तकालय का उपयोग करते समय वास्तव में देखता हूं।

दिलचस्प है, फियो, जिसमें से मैंने कुछ तरीकों को उधार लिया था, एक दूसरे पैमाने पर बिल्कुल 700-900 नैनोसेकंड खो देता है (और इसके तीन कारण हैं)। साथ ही, यह मानक लिनक्स प्रारूप में समय के भंडारण के कारण रूपांतरण की गति में खो देता है। हालांकि, मैं फियो प्रशंसकों को आश्वस्त करने के लिए जल्दबाजी करता हूं। मैंने डेवलपर्स को उन सभी रूपांतरण समस्याओं का विवरण भेजा है जिन्हें मैंने खोजा था । लोग पहले से ही काम कर रहे हैं, वे इसे जल्द ही ठीक कर देंगे।

मैं आपको कई सुखद नैनोसेकंड की कामना करता हूं!