statistics - लौकिक किरण: संभावना है कि वे एक कार्यक्रम को प्रभावित करेंगे?




physics probability (10)

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

यह अच्छी तरह से ज्ञात है कि सौर तूफान विद्युत प्रणालियों के साथ काफी हद तक हो सकता है (जैसे मार्च 1 9 8 9 में क्यूबेक पावर आउटेज )। यह काफी संभावना है कि कंप्यूटर सिस्टम भी प्रभावित हो सकते हैं।

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

बाद में, "ब्रह्मांडीय विकिरण" मेरे कार्यस्थल पर एक आंतरिक मजाक बन गया है। जब भी हमारे सर्वर के साथ कुछ होता है और हम इसके लिए कोई स्पष्टीकरण नहीं पा रहे हैं, तो हम मजाक कर गलती से "ब्रह्मांडीय विकिरण" को विशेषता देते हैं। :-)

एक बार फिर मैं एक डिजाइन समीक्षा में था, और दावा किया कि किसी विशेष परिदृश्य की संभावना कार्यक्रम को प्रभावित करने वाली "ब्रह्मांडीय किरणों के जोखिम से कम" थी, और यह मेरे लिए हुआ कि मेरे पास बेहद कम विचार नहीं था कि संभावना है।

"चूंकि 2 -128 340282366920938463463374607431768211456 में से 1 है, मुझे लगता है कि हम यहां हमारी संभावनाओं को लेने में उचित हैं, भले ही ये गणना कुछ अरबों के कारक से बंद हो ... हम ब्रह्मांडीय किरणों के लिए खतरे में हैं हमें पेंच, मुझे विश्वास है। "

क्या यह प्रोग्रामर सही है? एक कंप्यूटर पर हमला करने और कार्यक्रम के निष्पादन को प्रभावित करने वाली ब्रह्मांडीय किरण की संभावना क्या है?


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

इसके अलावा, कुछ घटकों को शोर को अवरुद्ध करने के लिए विद्युत रूप से संरक्षित किया जाता है (शायद मुझे लगता है कि ब्रह्मांडीय किरणें नहीं)।

लेकिन अंत में, जैसा कि अन्य उत्तरदाताओं ने कहा है, कभी-कभी थोड़ा या बाइट होता है जो घबरा जाता है, और यह मौका छोड़ दिया जाता है कि यह एक महत्वपूर्ण बाइट है या नहीं। सबसे अच्छा मामला परिदृश्य, एक ब्रह्मांडीय किरण खाली बिट्स में से एक को स्कैम्बल करता है और इसका कोई प्रभाव नहीं पड़ता है, या कंप्यूटर को दुर्घटनाग्रस्त करता है (यह एक अच्छी बात है, क्योंकि कंप्यूटर को नुकसान पहुंचाने से रोक दिया जाता है); लेकिन सबसे खराब मामला, ठीक है, मुझे यकीन है कि आप कल्पना कर सकते हैं।


ईसीसी के साथ आप लौकिक किरणों की 1 बिट त्रुटियों को सही कर सकते हैं। 10% मामलों से बचने के लिए जहां ब्रह्मांडीय किरणों के परिणामस्वरूप 2-बिट-त्रुटियां होती हैं, ईसीसी कोशिकाएं आमतौर पर चिप्स पर इंटरलीव होती हैं, इसलिए कोई भी दो कोशिकाएं एक दूसरे के बगल में नहीं होती हैं। एक ब्रह्मांडीय किरण घटना जो दो कोशिकाओं को प्रभावित करती है, इसलिए परिणामस्वरूप दो सुधार योग्य 1 बिट त्रुटियां होती हैं।

सूर्य कहता है: (भाग संख्या 816-5053-10 अप्रैल 2002)

आम तौर पर, ~ 10 से 100 एफआईटी / एमबी (1 एफआईटी = 1 डिवाइस 1 अरब घंटे में विफल) की दर से डीआरएएम मेमोरी में ब्रह्मांडीय रे मुलायम त्रुटियां होती हैं। इसलिए 10 जीबी मेमोरी वाली एक प्रणाली को हर 1,000 से 10,000 घंटों में एक ईसीसी कार्यक्रम दिखाना चाहिए, और 100 जीबी वाला एक सिस्टम हर 100 से 1,000 घंटे में एक कार्यक्रम दिखाएगा। हालांकि, यह एक अनुमानित अनुमान है जो ऊपर उल्लिखित प्रभावों के एक समारोह के रूप में बदल जाएगा।


खैर, ब्रह्मांडीय किरणों ने स्पष्ट रूप से टोयोटा कारों में इलेक्ट्रॉनिक्स को खराब करने का कारण बना दिया, इसलिए मैं कहूंगा कि संभावना बहुत अधिक है :)

क्या ब्रह्मांडीय किरण वास्तव में टोयोटा संकट का कारण बन रहे हैं?


डेटा बिंदु के रूप में, यह हमारे निर्माण पर हुआ था:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

एक संकलन के दौरान एक स्रोत फ़ाइल में एक बहुत ही महत्वपूर्ण जगह में, संकलन के दौरान होने वाली थोड़ी फ्लिप की तरह यह बहुत दृढ़ता से दिखता है।

मैं जरूरी नहीं कह रहा हूं कि यह एक "ब्रह्मांडीय किरण" थी, लेकिन लक्षण मेल खाता है।


नोट: यह उत्तर भौतिकी के बारे में नहीं है, लेकिन गैर-ईसीसी मेमोरी मॉड्यूल के साथ चुप स्मृति त्रुटियों के बारे में है। कुछ त्रुटियां बाहरी अंतरिक्ष से आ सकती हैं, और कुछ - डेस्कटॉप के आंतरिक स्थान से।

सीईआरएन क्लस्टर और Google डेटासेंटर जैसे बड़े सर्वर खेतों पर ईसीसी मेमोरी असफलताओं के कई अध्ययन हैं। ईसीसी के साथ सर्वर-क्लास हार्डवेयर सभी एकल त्रुटियों को पहचान और सही कर सकता है, और कई बहु-बिट त्रुटियों का पता लगा सकता है।

हम मान सकते हैं कि बहुत से गैर-ईसीसी डेस्कटॉप (और गैर-ईसीसी मोबाइल स्मार्टफोन) हैं। यदि हम ईसीसी-सुधार योग्य त्रुटि दर (एकल बिटफ्लिप्स) के लिए कागजात की जांच करते हैं, तो हम गैर-ईसीसी मेमोरी पर चुप स्मृति भ्रष्टाचार दर को जान सकते हैं।

इसलिए, यदि कार्यक्रम में बड़े डेटासेट (कई जीबी) हैं, या इसमें उच्च मेमोरी रीडिंग या लेखन दर (जीबी / एस या अधिक) है, और यह कई घंटों तक चलता है, तो हम डेस्कटॉप हार्डवेयर पर कई मूक बिट फ्लिप की उम्मीद कर सकते हैं। यह दर memtest द्वारा पता लगाने योग्य नहीं है, और डीआरएएम मॉड्यूल अच्छे हैं।

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

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

पीएस: अगर डीआरएएम मॉड्यूल खराब है तो चीजें बहुत खराब हो जाएंगी। उदाहरण के लिए, मैंने लैपटॉप में नया डीआरएएम स्थापित किया, जो कई हफ्ते बाद मर गया। यह बहुत मेमोरी त्रुटियों को देना शुरू कर दिया। मुझे क्या मिलता है: लैपटॉप लटकता है, लिनक्स रीबूट करता है, fsck चलाता है, रूट फाइल सिस्टम पर त्रुटियां पाता है और कहता है कि यह त्रुटियों को ठीक करने के बाद रीबूट करना चाहता है। लेकिन हर अगली रीबूट पर (मैंने उनमें से लगभग 5-6 किया) रूट फाइल सिस्टम पर अभी भी त्रुटियां मिली हैं।


मैंने इसका अनुभव किया है - ब्रह्मांडीय किरणों के लिए एक बिट फ्लिप करना दुर्लभ नहीं है, लेकिन यह बहुत ही असंभव है कि कोई व्यक्ति इसका निरीक्षण करता है।

मैं 2004 में एक इंस्टॉलर के लिए एक संपीड़न उपकरण पर काम कर रहा था। मेरा टेस्ट डेटा लगभग 500 एमबी या उससे अधिक डिकंप्रेस्ड की कुछ एडोब इंस्टॉलेशन फाइलें थीं।

एक थकाऊ संपीड़न चलाने के बाद, और अखंडता का परीक्षण करने के लिए एक डिकंप्रेशन चलाया जाता है, एफसी / बी ने एक बाइट अलग दिखाया।

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

लेकिन कुछ ने मुझे परीक्षण फिर से चलाने के लिए कहा। मैंने इसे चलाया और यह पारित हो गया। मैंने रात भर 5 बार परीक्षण चलाने के लिए एक स्क्रिप्ट स्थापित की। सुबह 5 सभी पास हो गए थे।

तो यह निश्चित रूप से एक ब्रह्मांडीय रे बिट फ्लिप था।


मैंने एक बार प्रोग्राम किए गए डिवाइस जो अंतरिक्ष में उड़ने के लिए थे, और फिर आप (माना जाता है कि, किसी ने कभी मुझे इसके बारे में कोई पेपर नहीं दिखाया, लेकिन इसे व्यवसाय में सामान्य ज्ञान कहा जाता था) ब्रह्मांडीय किरणों को हर समय त्रुटियों को प्रेरित करने की उम्मीद कर सकता था।


यह एक वास्तविक मुद्दा है, और यही वजह है कि सर्वर और एम्बेडेड सिस्टम में ईसीसी मेमोरी का उपयोग किया जाता है। और क्यों उड़ान प्रणाली जमीन आधारित लोगों से अलग हैं।

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

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

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


Wikipedia :

1 99 0 के दशक में आईबीएम द्वारा किए गए अध्ययन से पता चलता है कि कंप्यूटर आमतौर पर प्रति माह 256 मेगाबाइट रैम प्रति एक ब्रह्मांडीय-रे-प्रेरित त्रुटि का अनुभव करते हैं। [15]

इसका मतलब है प्रति माह 3.7 × 10-9 प्रति बाइट, या 1.4 × 10 -15 प्रति बाइट प्रति सेकंड की संभावना। यदि आपका प्रोग्राम 1 मिनट तक चलता है और 20 एमबी रैम पर रहता है, तो विफलता संभावना होगी

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

त्रुटि जांच विफलता के बाद को कम करने में मदद कर सकती है। इसके अलावा, जो द्वारा टिप्पणी की गई चिप्स के अधिक कॉम्पैक्ट आकार की वजह से, विफलता दर 20 साल पहले की तुलना में अलग हो सकती है।