लिनक्स कर्नेल गलत प्रोसेसर आवृत्ति का पता लगाता है

15

6.0.8 डेबियन सर्वर (HP ProLiant) के ठंडे बूट के बाद, ntpdसिस्टम समय के साथ कहर खेला: बिना किसी सीमा के बढ़ते सामान्य और विश्वसनीय संदर्भ समय सर्वर के संबंध में ऑफसेट और घबराना। (ध्यान दें कि एक जुड़वां समान सर्वर को कोई समस्या नहीं थी।) समस्या को ठीक करने के कई असफल प्रयासों के बाद ntpdमैंने रिबूट की कोशिश करने का फैसला किया, और सब कुछ ठीक हो गया।

समस्या की जांच करने के लिए मुझे यह विसंगति मिली, जो मेरी घड़ी की समस्याओं को समझा सकती है:

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

ध्यान दें कि दूसरे अंतिम बूट (समस्यात्मक एक) में पाया गया सीपीयू फ्रीक एक स्पष्ट रूपरेखा है। नाममात्र के संबंध में पता चला आवृत्ति की त्रुटि, त्रुटि और मानक विचलन के बिना +0.15 मेगाहर्ट्ज। 0.25 मेगाहर्ट्ज है। समस्याग्रस्त बूट के लिए मेरे पास -16.4 मेगाहर्ट्ज की त्रुटि है, जो उम्मीद से लगभग 100 गुना अधिक है।

मेरे सवाल:

क्या इस प्रकार की त्रुटि ntpसमय अनुशासन को अस्थिर / अनुपयोगी बना सकती है? क्या यह मेरी घड़ी की समस्याओं का कारण है?
क्या इस प्रकार का व्यवहार परतदार हार्डवेयर का लक्षण है? सर्वर hw रखरखाव में जाना चाहिए?

अपडेट करें

कुछ उपयोगी डेटा:

कर्नेल 2.6.32-5-amd64 (डेबियन 2.6.32-48seeee4) है
current_clocksource है tsc
के लिए त्रुटि lpj(बेशक) सीपीयू freq पर त्रुटि के साथ संगत है

उपरोक्त के लिए कुछ संदर्भ लाइनें grep

[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.004000] Detected 2400.110 MHz processor.
[    0.000008] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.22 BogoMIPS (lpj=9600440)

— स्टेफानो एम
स्रोत

5

मैंने खुद को आश्वस्त किया कि समस्या एक गलत समय स्टाम्प काउंटर (TSC) आवृत्ति थी।

जाहिर तौर पर कर्नेल टीएससी को प्रोग्रामेबल इंटरवल टाइमर (PIT) के खिलाफ कैलिब्रेट कर रहा है । आमतौर पर पहचाना गया सीपीयू आवृत्ति 2400.204 4 0.134 मेगाहर्ट्ज है, जो लगभग 56 पीपीएम सटीकता से मेल खाती है। समस्याग्रस्त बूट के बाद सीपीयू फ्रीक को 2383.579 मेगाहर्ट्ज के रूप में अनुमानित किया गया था, जो लगभग 6900 पीपीएम की त्रुटि से मेल खाती है, जिसकी ntpdभरपाई करने में सक्षम नहीं था। वास्तव में पहले 10h30m के कामकाज के दौरान सिस्टम घड़ी को लगभग 4m30s प्राप्त हुए, जो कि लगभग 7000 ppm है।

चूंकि टीएससी आवृत्ति में त्रुटि सिस्टम क्लॉक में बहाव से मेल खाती है इसलिए मैं निष्कर्ष निकालूंगा कि असामान्य घड़ी का व्यवहार गलत टीएससी अंशांकन के कारण हुआ था।

हालाँकि मैंने इतनी बड़ी समस्या कभी नहीं देखी: मैं अभी भी इस गलत अंशांकन के संभावित कारणों (hw, sw) के बारे में सोच रहा हूं।

— स्टेफानो एम
स्रोत

3

इस प्रकार का व्यवहार अत्याचारी है। एक अच्छा चेक यह देखने के लिए ntp.driftफ़ाइल के मूल्यों की निगरानी करना होगा कि क्या व्यवहार में बदलाव होने पर महत्वपूर्ण परिवर्तन होते हैं। यदि यह महत्वपूर्ण रूप से बदलता रहा, तो NTP एक समस्या के आसपास तिरछा होने का प्रयास कर रहा था। यदि ऐसा था, तो यह संकेत है कि कर्नेल ने स्टार्टअप पर सही घड़ी की आवृत्ति को गलत बताया, या बूट के गलत हिस्सों के लिए घड़ी ही धीमी थी। दुर्भाग्य से, यह एक घटना हार्डवेयर समस्याओं का स्पष्ट संकेत नहीं है।

यदि यह फिर से होता है, तो उस ntp.drift फ़ाइल को देखें।

— sysadmin1138
स्रोत

समस्याग्रस्त बूट के बाद ntpd एक स्थिर PLL में कभी नहीं आया, इसलिए ntpdc -c loopinfoमुझे एक आवृत्ति बहाव मूल्य कभी नहीं दिया। अब रिबूट के बाद सब कुछ क्रम में प्रतीत होता है, एक स्थिर बहाव मूल्य के साथ ... बीटीडब्ल्यू आपका सुझाव सही है, मैं log/loopstatsअसामान्य व्यवहार के लिए निगरानी कर रहा हूं ।

— स्टेफानो एम