दूसरी लीप - यह क्या है और कैसे "पुआल" रखना है

जैसा कि 30 जून, 2012 को हबेरा में पहले ही उल्लेख किया गया है , समन्वय का एक दूसरा पेश किया जाएगा।
यदि आप रुचि रखते हैं कि यह क्या है और यह किन परेशानियों का कारण बन सकता है, तो बिल्ली का स्वागत करें।

दूसरी लीप

दुर्भाग्य से, हमारी दुनिया को डिज़ाइन किया गया है ताकि पृथ्वी के घूर्णन का कोणीय वेग स्थिर न हो। इससे भी बदतर, इस गति का व्युत्पन्न स्थिर नहीं है। इससे दो अप्रिय निष्कर्ष निकलते हैं:

1. कोई फर्क नहीं पड़ता कि किस समय की लंबाई को एक सेकंड के मानक के रूप में चुना जाता है, थोड़ी देर के बाद, हमारे समय के पैमाने और सौर समय के बीच का अंतर, जिसे समायोजित करने की आवश्यकता है, प्रकट किया जाएगा;
2. समायोजन किसी भी नियमित आधार पर नहीं किया जा सकता है।

UTC और सौर औसत (UT1 ) के बीच अंतर की भरपाई के लिए एक लीप सेकेंड पेश किया जाता है। 30 जून या 31 दिसंबर को सार्वभौमिक समय के अनुसार दिन के अंत में समन्वय दूसरा दर्ज किया जाता है ताकि यूटीसी का समय UT1 से seconds 0.9 सेकंड से अधिक न हो। यह माना जाता है कि ऐसे दिनों में, 23:59:59 के बाद, यह 23:59:60 पर जाता है, या 23:59:58 के बाद अगला दूसरा दिन 00:00 बजे होगा।
चूंकि समायोजन किसी नियमित आधार पर नहीं किया जा सकता है, स्वायत्त घंटों का समायोजन मैन्युअल रूप से किया जाता है। बाहरी सिंक्रनाइज़ेशन वाली घड़ियों के मामले में, बाहरी स्रोत से प्राप्त आंकड़ों के आधार पर, समायोजन स्वचालित रूप से किया जा सकता है।

आगामी दूसरे समन्वय का प्रसार

अधिकांश स्थानीय समय सेवाएं और नेटवर्क समन्वय के आगामी दूसरे, जैसे कि जीपीएस के बारे में जानकारी प्रदान करते हैं। NTP यह जानकारी भी प्रदान करता है। मैं इस पर और अधिक विस्तार से ध्यान दूंगा।
NTP सर्वर तीन तरीकों से सिंक्रनाइज़ेशन के आगामी सेकंड के बारे में जान सकता है:

1. जानकारी को मैन्युअल रूप से सेट किया जा सकता है (ntpd के मामले में, यह लीपफाइल फ़ाइल का उपयोग करके किया जाता है, जिसमें सभी सेकंड्स के सिंक्रनाइज़ेशन और लीपफाइल निर्देश के बारे में जानकारी होती है);
2. संदर्भ समय स्रोत के चालक से जानकारी के माध्यम से;
3. NTP प्रोटोकॉल के माध्यम से।

इन विधियों में से किसी के द्वारा समन्वय के आगामी सेकंड के बारे में जानकारी प्राप्त करना, और दिन की शुरुआत के साथ, जिस पर यह दूसरा संदर्भित करता है, सर्वर आंतरिक चर के संबंधित मूल्य को निर्धारित करता है, ओएस कर्नेल को सूचित करता है और तदनुसार अपने ग्राहकों को सूचित करना शुरू करता है।
NTP प्रोटोकॉल डेटाग्राम समन्वय के एक दूसरे की घोषणा के लिए दो-बिट क्षेत्र प्रदान करता है। आमतौर पर दोनों बिट्स शून्य पर सेट होते हैं। बिट्स को एक में सेट करने का मतलब है कि दिन के अंत में समन्वय का एक सकारात्मक या नकारात्मक दूसरा दर्ज किया जाएगा (कुछ मामलों में दोनों बिट्स को एक में सेट किया जा सकता है, जिसका अर्थ है कि एक कारण या किसी अन्य के लिए सर्वर सटीक समय प्रदान नहीं कर सकता है)।
NTP सर्वर के एक सर्वेक्षण के परिणामों के अनुसार, एक वोट लिया जाता है, जिसके आधार पर ग्राहक आंतरिक चर का संबंधित मूल्य निर्धारित करता है, OS कर्नेल को समन्वय के आगामी दूसरे चरण के बारे में सूचित करता है और उसके अनुसार अपने ग्राहकों को सूचित करना शुरू करता है।
यह पूरी तरह से तर्कसंगत और व्यावहारिक योजना प्रतीत होगी, लेकिन एक रैक संभव है।

जेली

रेक आमतौर पर प्राथमिक सर्वरों के गलत कॉन्फ़िगरेशन के कारण होता है, जब सर्वर को समन्वय के आगामी सेकंड के बारे में कुछ भी नहीं पता होता है और इस तथ्य के बाद इसके बारे में सबसे अच्छा पता चलता है। इसका एक उदाहरण 1 जनवरी, 2009 को VNIIIFTRI (नेशनल मेट्रोलॉजिकल इंस्टीट्यूट ऑफ रशिया) के ntp- सर्वरों का व्यवहार है । विदेशी मामले भी हो सकते हैं जब एक सर्वर जो पूरी तरह से NTP का समर्थन नहीं करता है, या एक फ़ायरवॉल जो पैकेट को गलत तरीके से साफ करता है, को सिंक्रोनाइज़ेशन चेन में मिटा दिया जाता है।
स्ट्रैटम 1 सर्वर की त्रुटियां सबसे अधिक बार सामना होती हैं जब NMEA प्रोटोकॉल के साथ एक GPS या GLONACC रिसीवर का उपयोग एक संदर्भ स्रोत के रूप में किया जाता है, जो पहले से ही आए समन्वय दूसरे के बारे में जानकारी प्रसारित करता है। इसलिए यदि आप स्ट्रैटम 1 सर्वर के मालिक हैं और यह सुनिश्चित नहीं है कि आपके संदर्भ स्रोत का ड्राइवर आवश्यक जानकारी को स्थानांतरित करने में सक्षम होगा, तो कृपया अपने लीपफाइल सर्वर को "फ़ीड" करें।
Ntpd के लिए सर्वर कॉन्फ़िगरेशन की जाँच करना काफी सरल है। Ntpq -c rv कमांड दें। आपको कुछ इस तरह मिलेगा:

  associd = 0 स्थिति = 0419 leap_none, Sync_uhf_radio, 1 घटना, लीपयार्म,
 संस्करण = "ntpd 4.2.6p5@1.2349-o बुध जून 13 10:36:21 UTC 2012 (1),
 प्रोसेसर = "x86_64", सिस्टम = "लिनक्स / 3.2.20", लीप = 00, स्ट्रैटम = 1,
 परिशुद्धता = -22, rootdelay = 0.000, rootdisp = 0.002, refid = GPS,
 reftime = d3856e94.2052bbf0 शुक्र, 15 जून 2012 15: 19: 32.126,
 घड़ी = d3856e97.6bdc8f80 शुक्र, 15 जून 2012 15: 19: 35.421, सहकर्मी = 48525, टीसी = 3,
 टकसाल = 3, ऑफसेट = 0.001, आवृत्ति = 23.641, sys_jitter = 0.000,
 clk_jitter = 0.000, clk_wander = 0.001, tai = 34, leapsec = 201207010000,
 एक्सपायर = 201212280000 

यदि आप leapsec = 201207010000 देखते हैं, तो आपका सर्वर सही तरीके से कॉन्फ़िगर किया गया है और एक पर्याप्त छलांग का उपयोग करता है। यदि आप 30 जून को एक ही कमांड चलाते हैं, तो पहली पंक्ति में leap_none को leap_add_sec में बदलना चाहिए। आप यह सुनिश्चित कर सकते हैं कि 30 जून को आपके NTP ट्रैफ़िक का विश्लेषण करके सब कुछ हो। उदाहरण के लिए, -v विकल्प के साथ tcpdump सफलतापूर्वक NTP पैकेटों को पार्स करता है और उपर्युक्त घोषणा बिट्स को एक पठनीय रूप में प्रदर्शित करता है।
मैं ऑपरेटिंग सिस्टम के व्यवहार पर भी ध्यान देना चाहूंगा। यदि लिनक्स, फ्रीबीएसडी और अधिकांश आधुनिक यूनिक्स जैसे ऑपरेटिंग सिस्टम समन्वय के एक सेकंड को सही ढंग से संभालते हैं, तो विंडोज के लिए यह एक आश्चर्य के रूप में आएगा। कुछ समय में, विंडोज टाइम सर्विस यह पता लगाएगी कि ओएस का समय लगभग एक सेकंड से अलग है। क्या विंडोज इस अंतर की भरपाई धीरे-धीरे करेगा, सिस्टम क्लॉक को धीमा (तेजी से) करेगा, या झटका धीरे-धीरे MaxAllowedPhaseOffset पैरामीटर पर निर्भर करेगा। इस मामले में, आप प्रशासक को यह निर्धारित करने के लिए अनुशंसा कर सकते हैं कि कौन सा मुआवजा परिदृश्य कम से कम नुकसान का कारण बनेगा और इस पैरामीटर को तदनुसार निर्धारित करेगा।