Facebook ने नई time service पेश की
(engineering.fb.com)Facebook ने time.facebook.com पते पर नई NTP time service पेश की है। कंपनी का कहना है कि यह अन्य public time services की तुलना में अधिक accurate है, और users की पहचान IP address से नहीं करती। Facebook ने इस service से संबंधित एक पोस्ट अपने engineering blog पर भी प्रकाशित की है। (अंग्रेज़ी)
Facebook जैसी बड़ी IT कंपनियां time service में रुचि क्यों लेती हैं, इसका कारण distributed systems का संचालन है। Distributed databases में transactions को process करने या सही logging सुनिश्चित करने के लिए कई servers की clocks का उच्च precision के साथ synchronized होना ज़रूरी होता है।
Facebook ने Stratum 1 (ऐसा विशेष test equipment जो satellites की atomic clocks से सीधे time information प्राप्त करता है) उपकरण खरीदकर, पारंपरिक रूप से widely used time server ntpd और अपेक्षाकृत नए NTP daemon chrony( https://chrony.tuxfamily.org/ ) के बीच benchmark किया। ntpd ने शुरुआती startup के बाद अस्थायी रूप से -10 ms तक की error दिखाई और फिर धीरे-धीरे ±1 ms error पर converge हुआ। दूसरी ओर, chrony में अधिकांश errors लगातार ±0.2 ms के भीतर रहीं, जिससे यह ntpd की तुलना में काफी अधिक accurate साबित हुआ।
chrony के अन्य फायदे भी हैं। उनमें से एक है hardware timestamp का support। Time synchronization protocol NTP, server और client के बीच packets के आने-जाने पर timestamps लेकर transit time difference की गणना करता है, ताकि यथासंभव सटीक current time निकाला जा सके। लेकिन non-real-time operating systems में यह guarantee नहीं की जा सकती कि किसी process की latency एक निश्चित सीमा से नीचे ही रहेगी। यही बात NTP पर भी लागू होती है, और network के ज़रिए time synchronization में error बढ़ने के कारणों में से एक बनती है।
हालांकि, कुछ NICs (LAN cards) hardware timestamp feature को support करते हैं। इस feature में NIC अलग hardware के माध्यम से अपनी clock बनाए रखता है और timestamp processing करता है, जिससे processing delay केवल कुछ nanoseconds के स्तर तक सीमित रहती है। अगर local network environment हो और NTP server तथा client दोनों hardware timestamp को support करते हों, तो आदर्श स्थिति में 1 माइक्रोसेकंड से कम error के साथ भी time synchronization संभव हो सकता है। वास्तविक time service में local network environment नहीं होता, और कई बार client-side NIC hardware timestamp को support भी नहीं करता, इसलिए इतनी सटीकता की अपेक्षा करना कठिन है। फिर भी, chrony और hardware timestamp feature को मिलाकर किए गए benchmark में अधिकांश time synchronization errors ±0.1 ms के भीतर रहीं।
इसीलिए Facebook अपनी public time service को chrony में hardware timestamp enabled configuration के साथ चला रहा है। Google या Apple जैसी अन्य public time servers में दिए जाने वाले समय की error कभी-कभी ±2 ms से भी अधिक हो सकती है, जबकि Facebook की service में अधिकांश मामलों में यह ±1 ms के भीतर रहती है। जानकारी के लिए, यह service पांच अलग-अलग regions में endpoints के साथ संचालित होती है। अधिक जानकारी के लिए मूल लेख देखें।
7 टिप्पणियां
वाह। यह एक दिलचस्प लेख था। सटीकता के लिए किए गए प्रयास को संक्षिप्त(?) लेकिन विस्तार से साझा किया गया है। यह लेख पढ़ने के बाद मैंने अपने Mac के NTP server को
time3.facebook.comमें बदल दिया।मैं
time1.facebook.comइस्तेमाल कर रहा हूँ। ping चलाकर देखा तो 2 से 5 तक के दूसरे endpoints पर या तो ping नहीं जा रहा था, या फिर काफ़ी धीमा था।chronyमेंtime1.facebook.comको time server के रूप में सेट करने पर expected error थोड़ा-सा ±1 ms से ज़्यादा दिखता है। अगर सिर्फ़time.facebook.comसेट करूँ, तो समय मिल ही नहीं पाता।जानकारी के लिए, दूसरे time servers, जैसे
time.google.comयाtime.windows.com, बिना किसी अपवाद के 30 ms से अधिक की त्रुटि दिखाते हैं। यही बातkr.pool.ntp.orgजैसे NTP pools पर भी लागू होती है। अब तक मैंने जिन time servers को देखा है, उनमें समय की सबसे कम त्रुटि Stratum 1 serverntp.postech.ac.krमें मिली, औरchronyइसे लगभग ±5 ms के रूप में अनुमानित करता है।हाल ही में मुझे पता चला कि अगर chrony में
time.apple.comको Pool के रूप में सेट करें, तो कोरिया और जापान में मौजूद high-precision NTP सर्वर चुने जाते हैं। हैरानी की बात यह है कि वे Stratum 1 के रूप में दिखते हैं। लगता है Apple अपने CDN सर्वरों पर GPS रिसीवर लगाकर उन्हें time server की तरह इस्तेमाल कर रहा है।वाह, यह मज़ेदार है।
at Facebook scaleजैसा वाक्यांश अब तो परिचित लगने लगा है।यह थोड़ी अलग बात है, लेकिन GeekNews के Twitter पर यह पोस्ट नहीं दिखी—क्या Twitter bot द्वारा पोस्ट की जाने वाली खबरों के लिए कोई अलग शर्तें हैं?
आह, जांच करके देखा तो पता चला कि कैरेक्टर गिनकर काटकर पोस्ट करने वाले हिस्से में सबसे आगे मौजूद URL अपने-आप लिंक में बदल गया, और उसी वजह से कैरेक्टर सीमा पार हो गई, इसलिए Twitter API में एरर आया T_T
Twitter में URL को बिना शर्त शायद 22 bytes में बदल दिया जाता है.
लगता है इस हिस्से को ठीक करना पड़ेगा, उफ.