उच्च DPC ल्याटेन्सी भनेको ढिलो VPN मार्ग होइन

एउटा अडियो खराबी र एउटा VPN रोकावट एउटै दस सेकेन्डमा पर्छन्, र एउटा उपयोगिताले DPC ल्याटेन्सी भनी लेबल गरिएको उच्च संख्या रिपोर्ट गर्छ. ड्राइभरले सुरुङ ढिलो बनाइरहेको छ वा सुरुङले ड्राइभरमा दबाब दिइरहेको छ भन्ने निष्कर्ष निकाल्ने प्रलोभन हुन्छ. ती दुवै निष्कर्ष त्यो संख्याबाट निस्कँदैनन्.

यहाँ तीनवटा मापन खेलमा छन्, र तिनीहरूले एउटै सीमा साझा गर्दैनन्.

तीन संख्या, तीन सीमा

मुल्तबी राखिएको प्रक्रिया कल भनेको ड्राइभरले आफ्नो इन्टरप्ट ह्यान्डलरबाट पछि सार्ने काम हो, र ती रुटिनभित्र बिताइने समय प्रोसेसर-स्थानीय मापन हो जुन मोड्युल र फंक्शनहरूलाई श्रेय दिइन्छ. इको राउन्ड ट्रिप सकेटमा समयको अवलोकन हो, जुन नेटवर्क स्ट्याक र टाढाको उत्तरदाताले उत्पादन गर्छन्. डिस्कनेक्ट घटना क्लाइन्टले रेकर्ड गर्ने अवस्था-संक्रमण हो. प्रत्येकले अरूले दिन नसक्ने प्रश्नको उत्तर दिन्छ, र एउटै एकाइ भए पनि तिनीहरू अदलबदल गर्न मिल्ने हुँदैनन्.

उपयोगी अनुशासन भनेको मान पढ्नुअघि सीमाको नाम लिनु हो. एकाइ र सीमा सँगै लेख्नुहोस्. यदि कुनै उपकरणले मिलिसेकेन्ड रिपोर्ट गर्छ भने, कसको मिलिसेकेन्ड भनी सोध्नुहोस्: रुटिनभित्रको समय, चल्न पर्खने समय, वा उत्तर आउनुअघिको समय.

एउटा श्रेणीमा उच्च संख्या एउटा संकेत हो, कहिल्यै निदान होइन.

शीर्षक पछाडिको परिभाषा पढ्नुहोस्

उपयोगिताहरूले ल्याटेन्सी भन्ने कुरामा फरक पर्छ. कसैले ड्राइभर रुटिनको अवधि रिपोर्ट गर्छन्, कसैले तालिका ढिलाइ रिपोर्ट गर्छन्, र ती दुई मात्रा एउटै मेसिनमा विपरीत दिशामा जान सक्छन्. तीमध्ये एउटालाई मात्र DPC ल्याटेन्सी भन्ने ड्यासबोर्डले देखिनेभन्दा कम बताएको छ. त्यसैले दुई ड्यासबोर्डहरू केही पनि नबदलिएको मेसिनबारे असहमत हुन सक्छन्.

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

स्थानीय ड्राइभर काम र नेटवर्क ढिलाइ पनि नमिलीकन अन्तरक्रिया गर्छन्. अत्यधिक इन्टरप्ट-सम्बन्धी गतिविधिले मेसिनमा समय-संवेदनशील काम ढिलो गर्न सक्छ, र भीडभाड भएको मार्गले प्याकेट ढिलो गर्न सक्छ, र एउटै देखिने रोकावटका क्रममा दुवै सत्य हुन सक्छन्.

हरेक अवलोकन एउटै विन्डोमा राख्नुहोस्

लक्षण भएको अन्तराल पढेमा मात्र ट्रेस उपयोगी हुन्छ. ट्रेस, क्लाइन्टको घटना र अनुप्रयोगको असफलता समय-छापसहित रेकर्ड गर्नुहोस्, त्यसपछि ती सबैमा उही सेकेन्डहरू हेर्नुहोस्. एक घण्टाको ट्रेसको अधिकतम र त्यस दिउँसो पछि भएको डिस्कनेक्ट दुई असम्बन्धित तथ्य हुन्.

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

त्यसपछि विश्लेषण उपकरणमा ट्रेस खोल्नुहोस् र सम्पूर्ण क्याप्चरको सट्टा त्यो विन्डोभित्रको अवधिअनुसार क्रमबद्ध गर्नुहोस्. CPU विश्लेषणको निर्देशिका ले DPC/ISR अवधि दृश्यको वर्णन गर्छ, जसले समय मोड्युल र फंक्शनहरूलाई श्रेय दिन्छ.

तपाईं त्यहाँ हुँदा सुरुङसँग वास्तवमा के भयो भनी पुष्टि गर्नुहोस्. अनुप्रयोगको ट्राफिक थोरै बेर गुमाउनु भनेको क्लाइन्टले नयाँ वार्ता सुरु गरेको होइन, र सानो परीक्षणको सफलताले बाँकी सबै चलिरहेको प्रमाणित गर्दैन.

प्रमाणले देखाएको घटक बदल्नुहोस्

व्यस्त मोड्युल अनुसन्धानको ठाउँ हो, फैसला होइन. यसले अर्को घटक वा तपाईंले उत्पन्न गरेको कार्यभारले गर्दा भएको काम गरिरहेको हुन सक्छ. मोड्युलको नाम, उपकरण, ड्राइभर संस्करण र अवलोकित अन्तराल सँगै राख्नुहोस्, किनकि त्यही समूह हो जसमा आपूर्तिकर्ताले कार्य गर्न सक्छ.

प्रत्येक प्रयोगमा एउटा परिवर्तन नै नतिजाबाट सिक्ने एकमात्र तरिका हो. तार भएको तुलनाले दायरा साँघुरो बनाउँछ, तर यसले एकै समयमा रेडियो मार्ग र ड्राइभर गतिविधि बदल्छ, त्यसैले यसलाई प्रमाण होइन, संकेत मान्नुहोस्.

ट्रेसलाई संवेदनशील मान्नुहोस्. यसमा प्रक्रियाका नाम र वातावरणका विवरण हुन सक्छन्, त्यसैले यसको ठाउँ समर्थित क्याप्चर च्यानल हो, सार्वजनिक संलग्नता होइन. ट्रेस कुन अवलोकनको उत्तर दिनका लागि थियो भनी बताउनुहोस्.