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


546

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

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

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


42
"विनिंग लॉटरी: क्या संभावना है कि वे एक कार्यक्रम को प्रभावित करेंगे?"
kennytm

27
यह उस हिस्से पर निर्भर करता है जहां कार्यक्रम को निष्पादित किया जा रहा है और यह कितनी अच्छी तरह से परिरक्षित है। पृथ्वी पर, ब्रह्मांडीय किरण प्रवाह गहरी जगह की तुलना में बहुत कम है, या पृथ्वी की कक्षा के पास भी है। हबल स्पेस टेलीस्कोप, उदाहरण के लिए, कच्ची छवियों का निर्माण करता है जो ब्रह्मांडीय किरणों के निशान से युक्त होते हैं।
एडम हॉलिज

89
क्या इसका मतलब यह है कि अब से, जब कोई अगली बार finallyब्लॉकों के बारे में पूछता है , तो हमें इसे "हमेशा निष्पादित करता है, सिवाय इसके कि क्या कार्यक्रम से बाहर निकलता है, या अगर यह एक ब्रह्मांडीय किरण के साथ मारा जाता है" तो इसे योग्य बनाना होगा?
स्केफमैन

72
वर्षों पहले एक प्रोटोटाइप कण डिटेक्टर पर काम करते हुए, मैंने इसे "ऑउच!" हर बार यह एक ब्रह्मांडीय किरण से टकराया था। अच्छा समय ...
बीटा

8
सबसे दिलचस्प सवालों पर मैंने थोड़ी देर में यहां पढ़ा है। एक वास्तविक आंख खोलने वाला। फिर से खोलने के लिए मुझ पर भरोसा करें।
एगेल कुरियन

जवाबों:


308

से विकिपीडिया :

1990 के दशक में आईबीएम द्वारा किए गए अध्ययनों से पता चलता है कि कंप्यूटर आमतौर पर प्रति माह 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 साल पहले की तुलना में भिन्न हो सकती है।


10
अधिक महत्वपूर्ण बात, 1995 में सीपीयू के लिए चिप की सुविधा का आकार लगभग 0.35 featurem या 350nm था। यह अब 1/10 वां है जो 35nm पर आकार का है।
जो क्रैबग

18
क्या यह संभव है कि जोखिम को कम करने के बजाय, आकार में कमी से जोखिम बढ़ेगा क्योंकि यह प्रत्येक बिट की स्थिति को बदलने के लिए कम ऊर्जा लेगा?
रॉबर्ट

63
कम आकार निश्चित रूप से जोखिम बढ़ाता है। ब्रह्मांडीय किरणों के प्रभाव से बचने के लिए अंतरिक्ष वाहनों के लिए कठोर प्रोसेसर बहुत बड़ी सुविधा आकारों का उपयोग करते हैं।
जो रॉबर्ट

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

14
वाह! इसका मतलब है कि मेरे पीसी में लगभग 1 बाइट हर दो दिन में दूषित हो जाती है।
स्टीफन मोनोव

91

जाहिर है, महत्वहीन नहीं है। से इस न्यू साइंटिस्ट लेख , एक इंटेल पेटेंट आवेदन से एक उद्धरण:

"कॉस्मिक किरण से प्रेरित कंप्यूटर क्रैश हुआ है और उम्मीद है कि आवृत्ति में वृद्धि होगी क्योंकि उपकरणों (उदाहरण के लिए, ट्रांजिस्टर) का आकार चिप्स में कम हो जाता है। इस समस्या को अगले दशक में कंप्यूटर विश्वसनीयता का एक प्रमुख सीमक बनने का अनुमान है।"

आप यहां पूरा पेटेंट पढ़ सकते हैं ।


7
वे चिप के आकार में कमी के साथ क्यों बढ़ते हैं? निश्चित रूप से एक छोटी वस्तु की किरण की चपेट में आने की संभावना कम होती है (यानी एक दीवार पर एक टेनिस गेंद फेंकने की तुलना, एक स्टैंप पर फेंकने के लिए)
जोनाथन।

7
क्योंकि जैसे-जैसे घटकों का आकार सिकुड़ता है, वे कॉस्मिक किरणों के प्रति अधिक संवेदनशील हो जाते हैं।
ire_and_curses

4
हां, छोटे के हिट होने की संभावना कम होती है, लेकिन अधिक संभावना है कि हिट राज्य को प्रभावित करेगा।
जॉन हस्कल

2
@ire_and_curses [उद्धरण की जरूरत है]
Anko

8
@ नोको - यह स्पष्ट की तरह है। जैसा कि एक दिया गया घटक छोटा होता है, उसे थोड़ा सा सेट करने के लिए कम वोल्टेज और कम चार्ज की जरूरत होती है। यह बाहरी अंतरिक्ष से ऊर्जा के साथ नष्ट होने के लिए अधिक संवेदनशील बनाता है। हालाँकि, यहाँ आपके लिए एक प्रशस्ति पत्र है: जैसे LSI मेमोरी डिवाइस छोटे हो जाते हैं, वे परमाणु-विकिरण-प्रेरित सॉफ्ट फेल के प्रति अधिक संवेदनशील हो जाते हैं।
ire_and_curses

55

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

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

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

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

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

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

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


9
BH 2011 की अतिरिक्त सामग्री: "Bitsquatting। DNS शोषण के बिना अपहरण" मीडिया ।blackhat.com/bh-us-11/Dinaburg/… लगभग 10000-30000 FIT / Mbit के लिए आधुनिक मल्टी-जीबी DRAMs सूचीबद्ध करता है (100 घंटे से कम) हर 128MB के लिए त्रुटियाँ)। पेपर उन लेखों को भी सूचीबद्ध करता है जो यह निष्कर्ष निकालते हैं कि अधिकांश नरम त्रुटियां विकिरण से होती हैं, लगभग सभी मामलों में - कॉस्मिक किरणों से, और कुछ मामले पीसी के अंदर अल्फा-एमिटर से। बीएच लेखकों ने प्रयोग किया और डोमेन के लिए 50000 एक्सेस प्राप्त किया, लोकप्रिय साइटों से 1 बिट बदला
ऑसगैक्स

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

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

2
Google के पेपर में यह एक मामले की तरह दिखता है कि कुछ रैम खराब है लगभग एक तिहाई मशीनें और हमारे बेड़े में 8% से अधिक डीआईएमएम प्रति वर्ष कम से कम एक सही त्रुटि देखी गई। सुधारात्मक त्रुटियों की हमारी प्रति-डीआईएमएम दर औसतन 25,000-75,000 FIT (ऑपरेशन के समय प्रति बिलियन घंटे में विफलताएं) प्रति Mbit और 778 की औसत दर्जे की FIT रेंज में बदल जाती है - 25,000 प्रति Mbit (त्रुटियों के साथ DIMM के लिए माध्यिका)। जबकि पूर्व-विचूर्ण अध्ययन 200-5,000 FIT प्रति Mbit की रिपोर्ट करते हैं। DIMM प्रति सही योग्य त्रुटियों की संख्या अत्यधिक परिवर्तनशील है, कुछ DIMM में अन्य की तुलना में बड़ी संख्या में त्रुटियों का अनुभव होता है।
vartec 15

31

विकिपीडिया 90 के दशक में आईबीएम द्वारा एक अध्ययन का हवाला देते हुए कहता है कि "कंप्यूटर आमतौर पर प्रति माह 256 मेगाबाइट रैम प्रति कॉस्मिक-रे-प्रेरित त्रुटि के बारे में अनुभव करते हैं।" दुर्भाग्य से प्रशस्ति पत्र वैज्ञानिक अमेरिकी में एक लेख के लिए था, जिसने आगे कोई संदर्भ नहीं दिया। व्यक्तिगत रूप से, मुझे लगता है कि यह संख्या बहुत अधिक है, लेकिन शायद कॉस्मिक किरणों से प्रेरित अधिकांश मेमोरी त्रुटियां वास्तविक या ध्यान देने योग्य समस्याओं का कारण नहीं बनती हैं।

दूसरी ओर, सॉफ्टवेयर परिदृश्यों की बात होने पर प्रायिकता के बारे में बात करने वाले लोगों के पास आमतौर पर कोई सुराग नहीं होता है कि वे किस बारे में बात कर रहे हैं।


7
थोड़ा फ़्लिप होने की संभावना को कार्यक्रम पर ध्यान देने योग्य प्रभाव होने की संभावना से गुणा किया जाना चाहिए। मुझे लगता है कि दूसरी संभावना आपके विचार से बहुत कम है।
मार्क रैंसम

2
@ मर्क: विशिष्ट कंप्यूटर प्रोग्रामों में उस तरह का फॉल्ट-टॉलरेंस बिल्ट-इन नहीं होता है। यदि टूटे हुए कोड को निष्पादित किया जाता है, तो प्रोग्राम कोड में एकल-बिट त्रुटि प्रोग्राम के दुर्घटनाग्रस्त होने की संभावना अधिक होगी।
रॉबर्ट हार्वे

75
हां, लेकिन अधिकांश मेमोरी में डेटा होता है, जहां फ्लिप उस विज़िबल नहीं होगा।
जूल

34
@zoul। 'visiblp' पर योग्य, लेकिन अगर e = 1100101 और p = 1110000 तो आप 3 बिट फ़्लिप के दुर्भाग्यपूर्ण शिकार हैं !
पॉल जीआर

10
@Paul: या एक उंगली की ब्लिप।
एमपीएन

30

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

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


23
"संघीय नियामक अध्ययन कर रहे हैं कि क्या टॉयटोटा में अचानक त्वरण ब्रह्मांडीय किरणों से जुड़ा हुआ है।" यही कारण है कि आपको अपने जीवन पर संघीय नियामकों को कभी भी शक्ति नहीं देनी चाहिए।

13
मुझे लगता है कि यहाँ सिद्धांत यह है कि ब्रह्मांडीय किरणें पुराने दिमागों में बिट्स को प्रवाहित कर रही हैं, जिससे उन्हें खराबी होती है और गलत पेडल दबाते हैं।
नॉक्स

16
"जाहिरा तौर पर"? मैं कहूंगा कि इस बिंदु पर एक जंगली अनुमान है। मेरा अपना अनुमान है कि यह घटना एम्बेडेड सिस्टम (वास्तव में सबसे जटिल कंप्यूटर सिस्टम) की उस पुरानी दुःस्वप्न का परिणाम है - दौड़ की स्थिति।
माइकल बूर

7
@Knox: अपने पुराने टिनफ़ोइल टोपी हट जाओ, यह है उपयोगी!

3
यह एक मजाक नहीं हो सकता है। मैंने कुछ गंभीर रूप से अजीब चीजें देखी हैं जैसे पहले होती थीं। उतना दुर्लभ नहीं जितना कि ज्यादातर लोग सोचते हैं।
ब्रायन नोब्लुच

25

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

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

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


17

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

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

दिलचस्प लिंक: http://cr.yp.to/hardware/ecc.html

दुर्भाग्य से पृष्ठ में Corsair लिंक मृत प्रतीत होता है।


कॉस्मिक किरण बिटफ़्लिप को समान रूप से वितरित नहीं किया जा सकता है, खासकर अगर हम "कॉस्मिक रे ईवेंट" के तहत सौर तूफानों को शामिल करते हैं -मबरला। यदि आपको एक ही बाइट के भीतर दो या अधिक बिटफ़्लिप्स मिले हैं, तो विशिष्ट ईसीसी त्रुटि को ठीक करने में सक्षम नहीं होगा।
टोबेकेन

@tobixen डबल बिट त्रुटि का पता लगाना खराब डेटा के साथ चलने से बेहतर है। ECC के बाद अगला कदम है DIMM मिररिंग के साथ चिपकिल ...
jmm

13

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

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

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

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


कॉस्मिक किरण बिटफ़्लिप को समान रूप से वितरित नहीं किया जा सकता है, खासकर अगर हम "कॉस्मिक रे ईवेंट" के तहत सौर तूफानों को शामिल करते हैं -मबरला। अचानक फटने से बाइट के भीतर कई बिटफ्लिप्स हो सकते हैं, और ईसीसी-एल्गोरिदम एक विफलता को ठीक करने में सक्षम नहीं होंगे।
तोबिक्सन

12

यदि कोई कार्यक्रम जीवन-महत्वपूर्ण है (यह किसी को मार देगा यदि यह विफल हो जाता है), तो इसे इस तरह से लिखना होगा कि यह या तो विफल-सुरक्षित होगा, या ऐसी विफलता से स्वचालित रूप से पुनर्प्राप्त होगा। अन्य सभी कार्यक्रम, वाईएमएमवी।

तोयोटास बिंदु में एक मामला है। कहें कि आप एक थ्रॉटल केबल के बारे में क्या कहेंगे, लेकिन यह सॉफ्टवेयर नहीं है।

Http://en.wikipedia.org/wiki/Therac-25 भी देखें


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

3
@ ब्रायन: अच्छा सॉफ्टवेयर यह पता लगा लेता था कि डेटा पॉइंट बंद थे, और निष्कर्ष निकाला कि डेटा खराब था।
रॉबर्ट हार्वे

..और फिर क्या ... अच्छा डेटा चाहिए। यह जानते हुए कि यह बुरा है कोई मदद नहीं करता है। ऐसा कुछ नहीं जो आप जादुई तरीके से काम कर सकें।
ब्रायन नोब्लुच

3
@ ब्रायन: ठीक है, एक बात के लिए, आप ज्ञान के आधार पर सुधारात्मक कार्रवाई कर सकते हैं कि आपका डेटा खराब है। उदाहरण के लिए, आप तेजी को रोक सकते हैं।
रॉबर्ट हार्वे

हाँ, आप कर सकते हैं (और चाहिए) चीकस डेटा। बेस्ट एंड-टू-एंड। हालाँकि यह केवल भ्रष्टाचार की संभावना को कम करता है। कल्पना करें कि आपका "यह वैध है" निर्देश मेमोरी या सीपीयू रजिस्टर में थोड़ा भ्रष्ट हो जाता है, जब आप त्रुटि हैंडलर को शाखा देना चाहते हैं।
eckes

11

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


8
वायुमंडल के ऊपर दो चीजें होती हैं: 1) कुल प्रवाह 2 अधिक है) यह बहुत अधिक भारी, बहुत ऊर्जावान कणों (एक छोटी सी जगह में थोड़ा सा पैक करने के लिए पर्याप्त ऊर्जा के साथ) के रूप में आता है।
dmckee --- पूर्व-मध्यस्थ ने बिल्ली का बच्चा

संदर्भों के संबंध में, इस विषय पर पुस्तकें (उदाहरण के लिए, books.google.com/books?hl=en&lr=&id=Er5_rzW0q3MC ), सम्मेलन (जैसे, radecs2015.org , seemapld.org , और अन्य), और पत्र-पत्रिकाएँ हैं। । कॉस्मिक किरणें एयरोस्पेस में एक मजाक नहीं हैं। वे एक प्रमुख कारण हैं कि कई अंतरिक्ष यान रेड हार्ड कंप्यूटर का उपयोग करते हैं, जिनमें से अधिकांश में आधुनिक स्मार्ट टोस्टर ओवन की प्रसंस्करण शक्ति होती है।
डेविड हैमेन

8

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

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

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

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


7

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

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

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


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

5

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

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

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

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

लेकिन कुछ ने मुझे फिर से परीक्षा चलाने के लिए कहा। मैंने उसे दौड़ाया और वह गुजर गया। मैंने 5 बार रातोंरात टेस्ट चलाने के लिए एक स्क्रिप्ट तैयार की। सुबह सभी 5 पास हो चुके थे।

तो यह निश्चित रूप से एक कॉस्मिक किरण सा था।


निश्चित रूप से? क्या यह एक असिंचित वैरिएबल नहीं हो सकता था जो बाद के परीक्षणों में एक बुरा प्रारंभिक मूल्य नहीं मिला?
doug65536 21

मैं हमेशा वी 3 या डब्ल्यू 4 के साथ वीएस पर संकलित करता हूं - साथ ही तर्कसंगत शुद्धिकरण, उस तरह के कोई कीड़े नहीं थे।
21_49 में rep_movsd

क्षमा करें, मुझे नहीं पता था कि उन संकलक विकल्प और तर्कसंगत शुद्ध पूरी तरह से अचूक थे। =)
डग ६५५३६

यह देखते हुए कि कोड तब उत्पादन में डाल दिया गया था और सैकड़ों जीबी को ठीक से संकुचित और असंपीड़ित किया गया था, एक समान बग का कोई संकेत नहीं था।
rep_movsd

4

तुम भी गलती सहिष्णु हार्डवेयर पर एक नज़र रखना चाहते हो सकता है।

उदाहरण के लिए स्ट्रेटस टेक्नोलॉजी ने विंटेल सर्वर का निर्माण किया, जिसे फुटसेवर कहा जाता है, जिसमें संगणना के परिणाम की तुलना करते हुए, लॉक-स्टेप में 2 या 3 "मेनबोर्ड" थे। (यह कभी-कभी अंतरिक्ष वाहनों में भी किया जाता है)।

स्ट्रैटस सर्वर कस्टम चिपसेट से बैकप्लेन पर लॉकस्टेप तक विकसित हुआ।

एक बहुत ही समान (लेकिन सॉफ्टवेयर) प्रणाली हाइपरविजर पर आधारित VMWare फॉल्ट टॉलरेंस लॉकस्टेप है।


4

डेटा बिंदु के रूप में, यह सिर्फ हमारे बिल्ड पर हुआ:

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  - ^

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.