Kosmische Strahlen: Wie hoch ist die Wahrscheinlichkeit, dass sie ein Programm beeinflussen?

Wieder einmal war ich in einer Entwurfsprüfung und stieß auf die Behauptung, dass die Wahrscheinlichkeit eines bestimmten Szenarios "geringer als das Risiko kosmischer Strahlung" sei, die das Programm beeinflusst, und mir fiel ein, dass ich nicht die geringste Ahnung hatte, was das ist Wahrscheinlichkeit ist.

"Da 2 ^-128 1 von 340282366920938463463374607431768211456 ist, denke ich, dass wir berechtigt sind, hier unser Risiko einzugehen, auch wenn diese Berechnungen um einen Faktor von einigen Milliarden abweichen ... Wir sind einem viel höheren Risiko für kosmische Strahlung ausgesetzt vermasseln Sie uns, glaube ich. "

Ist dieser Programmierer korrekt? Wie groß ist die Wahrscheinlichkeit, dass ein kosmischer Strahl auf einen Computer trifft und die Ausführung des Programms beeinflusst?

Aus Wikipedia :

Studien von IBM in den 1990er Jahren legen nahe, dass Computer in der Regel etwa einen durch kosmische Strahlung verursachten Fehler pro 256 Megabyte RAM pro Monat aufweisen. ^[fünfzehn]

Dies bedeutet eine Wahrscheinlichkeit von 3,7 × 10 ^–9 pro Byte und Monat oder 1,4 × 10 ^–15 pro Byte und Sekunde. Wenn Ihr Programm 1 Minute lang ausgeführt wird und 20 MB RAM belegt, ist die Ausfallwahrscheinlichkeit hoch

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

Eine Fehlerprüfung kann dazu beitragen, die Folgen eines Fehlers zu verringern. Aufgrund der kompakteren Größe der Chips, wie von Joe kommentiert, kann sich die Ausfallrate von der vor 20 Jahren unterscheiden.

Anscheinend nicht unbedeutend. Aus diesem New Scientist-Artikel ein Zitat aus einer Intel-Patentanmeldung:

"Durch kosmische Strahlung verursachte Computerabstürze sind aufgetreten und werden voraussichtlich mit der Frequenz zunehmen, wenn Geräte (z. B. Transistoren) in Chips kleiner werden. Dieses Problem wird voraussichtlich in den nächsten zehn Jahren zu einem wesentlichen Begrenzer der Computerzuverlässigkeit."

Das vollständige Patent können Sie hier lesen .

Hinweis: Bei dieser Antwort geht es nicht um Physik, sondern um stille Speicherfehler mit Nicht-ECC-Speichermodulen. Einige Fehler können aus dem Weltraum stammen, andere aus dem Innenraum des Desktops.

Es gibt mehrere Studien zu ECC-Speicherfehlern in großen Serverfarmen wie CERN-Clustern und Google-Rechenzentren. Hardware der Serverklasse mit ECC kann alle Einzelbitfehler erkennen und korrigieren sowie viele Mehrbitfehler erkennen.

Wir können davon ausgehen, dass es viele Nicht-ECC-Desktops (und Nicht-ECC-Smartphones) gibt. Wenn wir die Papiere auf ECC-korrigierbare Fehlerraten (einzelne Bitflips) überprüfen, können wir die Rate der stillen Speicherbeschädigungen im Nicht-ECC-Speicher ermitteln.

• Groß angelegte CERN 2007-Studie "Datenintegrität" : Anbieter geben " Bitfehlerrate von ^10-12 für ihre Speichermodule " an, " eine beobachtete Fehlerrate ist 4 Größenordnungen niedriger als erwartet ". Bei datenintensiven Aufgaben (8 GB / s Speicherlesen) bedeutet dies, dass jede Minute ( ^10-12 BER-Anbieter) oder alle zwei Tage ( ^10-16 BER) ein Einzelbit-Flip auftreten kann .

• In Googles Artikel "DRAM-Fehler in freier Wildbahn: Eine groß angelegte Feldstudie" aus dem Jahr 2009 heißt es, dass es bis zu 25000 bis 75000 Ein-Bit-FIT pro Mbit (Zeitfehler pro Milliarde Stunden ) geben kann, was 1 bis 5 Bit entspricht Fehler pro Stunde für 8 GB RAM nach meinen Berechnungen. Das Papier sagt dasselbe: " Mittlere korrigierbare Fehlerraten von 2000 bis 6000 pro GB und Jahr ".

• Sandia-Bericht 2012 "Erkennung und Korrektur von Datenverfälschungen im Hintergrund für High-Performance-Computing in großem Maßstab" : "Doppelbit-Flips wurden als unwahrscheinlich angesehen", aber bei ORNLs dichtem Cray XT5 sind sie "sogar mit einer Rate von einem pro Tag für mehr als 75.000 DIMMs" mit ECC. Und Einzelbitfehler sollten höher sein.

Wenn das Programm also über einen großen Datensatz (mehrere GB) oder eine hohe Lese- oder Schreibrate (GB / s oder mehr) verfügt und mehrere Stunden läuft, können wir auf Desktop-Hardware mit bis zu mehreren stillen Bit-Flips rechnen. Diese Rate kann von memtest nicht erkannt werden, und DRAM-Module sind gut.

Lange Cluster-Läufe auf Tausenden von Nicht-ECC-PCs, wie z. B. das internetweite Grid-Computing von BOINC, weisen immer Fehler aufgrund von Speicher-Bit-Flips sowie aufgrund von Fehlern bei der Festplatte und im Netzwerk auf.

Und für größere Computer (10 Tausend Server) kann es auch mit ECC-Schutz vor Einzelbitfehlern, wie wir im Sandia-Bericht 2012 sehen, jeden Tag Doppelbit-Flips geben, sodass Sie keine Chance haben, parallel in voller Größe zu arbeiten Programm für mehrere Tage (ohne regelmäßige Überprüfung und Neustart vom letzten guten Prüfpunkt im Falle eines doppelten Fehlers). Die riesigen Maschinen erhalten auch Bit-Flips in ihren Caches und CPU-Registern (sowohl architektonische als auch interne Chip-Trigger, z. B. im ALU-Datenpfad), da nicht alle von ihnen durch ECC geschützt sind.

PS: Es wird viel schlimmer, wenn das DRAM-Modul schlecht ist. Zum Beispiel habe ich einen neuen DRAM in einen Laptop installiert, der einige Wochen später verstarb. Es gab viele Speicherfehler. Was ich bekomme: Laptop hängt, Linux startet neu, führt fsck aus, findet Fehler im Root-Dateisystem und sagt, dass er nach der Korrektur von Fehlern einen Neustart durchführen möchte. Aber bei jedem nächsten Neustart (ich habe ungefähr 5-6 davon gemacht) werden immer noch Fehler im Root-Dateisystem gefunden.

Wikipedia zitiert eine Studie von IBM in den 90er Jahren, wonach "Computer normalerweise einen durch kosmische Strahlung verursachten Fehler pro 256 Megabyte RAM pro Monat aufweisen". Leider bezog sich das Zitat auf einen Artikel in Scientific American, der keine weiteren Hinweise gab. Persönlich finde ich diese Zahl sehr hoch, aber vielleicht verursachen die meisten durch kosmische Strahlung verursachten Gedächtnisfehler keine tatsächlichen oder wahrnehmbaren Probleme.

Auf der anderen Seite haben Leute, die über Wahrscheinlichkeiten sprechen, wenn es um Software-Szenarien geht, normalerweise keine Ahnung, wovon sie sprechen.

Nun, kosmische Strahlung hat anscheinend zu einer Fehlfunktion der Elektronik in Toyota-Autos geführt, daher würde ich sagen, dass die Wahrscheinlichkeit sehr hoch ist :)

Verursachen kosmische Strahlen wirklich Toyota-Leiden?

Mit ECC können Sie die 1-Bit-Fehler von Cosmic Rays korrigieren. Um die 10% der Fälle zu vermeiden, in denen kosmische Strahlung zu 2-Bit-Fehlern führt, werden die ECC-Zellen typischerweise über Chips verschachtelt, sodass keine zwei Zellen nebeneinander liegen. Ein kosmisches Strahlenereignis, das zwei Zellen betrifft, führt daher zu zwei korrigierbaren 1-Bit-Fehlern.

Sonnenzustände: (Teile-Nr. 816-5053-10 April 2002)

Im Allgemeinen treten im DRAM-Speicher weiche Fehler bei kosmischen Strahlen mit einer Rate von ~ 10 bis 100 FIT / MB auf (1 FIT = 1 Geräteausfall in 1 Milliarde Stunden). Ein System mit 10 GB Speicher sollte also alle 1.000 bis 10.000 Stunden ein ECC-Ereignis anzeigen, und ein System mit 100 GB würde alle 100 bis 1.000 Stunden ein Ereignis anzeigen. Dies ist jedoch eine grobe Schätzung, die sich in Abhängigkeit von den oben beschriebenen Effekten ändern wird.

Speicherfehler sind real und der ECC-Speicher hilft. Richtig implementierter ECC-Speicher korrigiert Einzelbitfehler und erkennt Doppelbitfehler (Anhalten des Systems, wenn ein solcher Fehler erkannt wird). Sie können dies daran erkennen, wie regelmäßig sich Leute über ein scheinbares Softwareproblem beschweren, das durch Ausführen von Memtest86 und gelöst wird schlechtes Gedächtnis entdecken. Natürlich unterscheidet sich ein vorübergehender Fehler, der durch eine kosmische Strahlung verursacht wird, von einem durchweg fehlerhaften Speicher, aber er ist relevant für die umfassendere Frage, wie sehr Sie darauf vertrauen sollten, dass Ihr Speicher ordnungsgemäß funktioniert.

Eine Analyse basierend auf einer residenten Größe von 20 MB ist möglicherweise für einfache Anwendungen geeignet, aber große Systeme verfügen routinemäßig über mehrere Server mit großen Hauptspeichern.

Interessanter Link: http://cr.yp.to/hardware/ecc.html

Der Corsair-Link auf der Seite scheint leider tot zu sein.

Dies ist ein echtes Problem, und deshalb wird ECC-Speicher in Servern und eingebetteten Systemen verwendet. Und warum Flugsysteme sich von bodengestützten unterscheiden.

Beachten Sie beispielsweise, dass Intel-Teile, die für "eingebettete" Anwendungen bestimmt sind, dazu neigen, dem Datenblatt ECC hinzuzufügen. Einem Bay Trail für ein Tablet fehlt es, da dies den Speicher etwas teurer und möglicherweise langsamer machen würde. Und wenn ein Tablet ein Programm jedes Mal in einem blauen Mond zum Absturz bringt, ist es dem Benutzer egal. Die Software selbst ist ohnehin weit weniger zuverlässig als die HW. Für SKUs, die für den Einsatz in Industriemaschinen und Automobilen vorgesehen sind, ist ECC obligatorisch. Da wir hier erwarten, dass die SW weitaus zuverlässiger ist und Fehler durch zufällige Störungen ein echtes Problem darstellen.

Systeme, die nach IEC 61508 und ähnlichen Standards zertifiziert sind, verfügen normalerweise sowohl über Starttests, mit denen überprüft wird, ob der gesamte Arbeitsspeicher funktionsfähig ist (keine Bits stecken bei Null oder Eins fest), als auch über eine Fehlerbehandlung zur Laufzeit, mit der versucht wird, von ECC erkannte Fehler zu beheben Oft auch Speicher-Scrubber-Aufgaben, die Speicher durchlaufen und kontinuierlich lesen und schreiben, um sicherzustellen, dass auftretende Fehler bemerkt werden.

Aber für Mainstream-PC-Software? Keine große Sache. Für einen langlebigen Server? Verwenden Sie ECC und einen Fehlerbehandler. Wenn ein nicht korrigierbarer Fehler den Kernel tötet, soll es so sein. Oder Sie werden paranoid und verwenden ein redundantes System mit Lock-Step-Ausführung, sodass bei einer Beschädigung eines Kerns der andere übernehmen kann, während der erste Kern neu gestartet wird.

Wenn ein Programm lebenswichtig ist (es tötet jemanden, wenn es fehlschlägt), muss es so geschrieben werden, dass es entweder ausfallsicher ist oder sich automatisch von einem solchen Fehler erholt. Alle anderen Programme, YMMV.

Toyotas sind ein typisches Beispiel. Sagen Sie, was Sie von einem Gaszug halten, aber es ist keine Software.

Siehe auch http://en.wikipedia.org/wiki/Therac-25

Ich habe einmal Geräte programmiert, die im Weltraum fliegen sollten, und dann konnten Sie (angeblich hat mir noch niemand ein Papier darüber gezeigt, aber es soll allgemein bekannt sein) erwarten, dass kosmische Strahlung ständig Fehler hervorruft.

"kosmische Strahlenereignisse" werden in vielen der Antworten hier als gleichmäßig verteilt angesehen. Dies ist möglicherweise nicht immer der Fall (dh Supernovae). Obwohl "kosmische Strahlung" per Definition (zumindest laut Wikipedia) aus dem Weltraum stammt, denke ich, dass es fair ist, auch lokale Sonnenstürme (auch bekannt als koronaler Massenauswurf unter demselben Dach) einzubeziehen. Ich glaube, dies könnte dazu führen, dass mehrere Bits innerhalb von a kippen kurze Zeitspanne, möglicherweise genug, um sogar ECC-fähigen Speicher zu beschädigen.

Es ist bekannt, dass Sonnenstürme mit elektrischen Systemen einiges an Chaos anrichten können (wie der Stromausfall in Quebec im März 1989 ). Es ist sehr wahrscheinlich, dass auch Computersysteme betroffen sein können.

Vor ungefähr 10 Jahren saß ich direkt neben einem anderen Mann, wir saßen mit jedem unserer Laptops, es war in einer Zeit mit ziemlich "stürmischem" Sonnenwetter (in der Arktis konnten wir dies indirekt beobachten - viele Aurora Borealis zu gesehen werden). Plötzlich - im selben Moment - stürzten unsere beiden Laptops ab. Er hatte OS X und ich Linux. Keiner von uns ist es gewohnt, dass Laptops abstürzen - dies ist unter Linux und OS X ziemlich selten. Häufige Softwarefehler können mehr oder weniger ausgeschlossen werden, da wir auf verschiedenen Betriebssystemen ausgeführt wurden (und dies geschah nicht während eines Sprunges) zweite). Ich bin gekommen, um dieses Ereignis der "kosmischen Strahlung" zuzuschreiben.

Später ist "kosmische Strahlung" an meinem Arbeitsplatz zu einem internen Witz geworden. Immer wenn mit unseren Servern etwas passiert und wir keine Erklärung dafür finden können, führen wir den Fehler scherzhaft auf "kosmische Strahlung" zurück. :-)

Häufiger kann Rauschen Daten beschädigen. Prüfsummen werden verwendet, um dies auf vielen Ebenen zu bekämpfen. In einem Datenkabel befindet sich normalerweise ein Paritätsbit , das sich neben den Daten bewegt . Dies verringert die Wahrscheinlichkeit einer Korruption erheblich . Auf Analyseebenen werden Unsinndaten normalerweise ignoriert. Selbst wenn eine Beschädigung das Paritätsbit oder andere Prüfsummen überschritten hat, werden sie in den meisten Fällen ignoriert.

Außerdem sind einige Komponenten elektrisch abgeschirmt , um Rauschen auszublenden (wahrscheinlich keine kosmischen Strahlen, denke ich).

Aber am Ende, wie die anderen Antwortenden gesagt haben, wird gelegentlich ein Bit oder Byte verschlüsselt, und es bleibt dem Zufall überlassen, ob dies ein signifikantes Byte ist oder nicht. Im besten Fall verschlüsselt ein kosmischer Strahl eines der leeren Bits und hat absolut keine Auswirkung oder stürzt den Computer ab (dies ist eine gute Sache, da der Computer keinen Schaden anrichtet). Aber im schlimmsten Fall können Sie sich das sicher vorstellen.

Ich habe dies erlebt - Es ist nicht selten, dass kosmische Strahlen ein bisschen umdrehen, aber es ist sehr unwahrscheinlich, dass eine Person dies beobachtet.

Ich habe 2004 an einem Komprimierungswerkzeug für ein Installationsprogramm gearbeitet. Meine Testdaten waren einige Adobe-Installationsdateien mit einer Größe von mindestens 500 MB, die dekomprimiert wurden.

Nach einem langwierigen Komprimierungslauf und einem Dekomprimierungslauf zum Testen der Integrität zeigte FC / B ein Byte Unterschied.

Innerhalb dieses einen Bytes war das MSB umgedreht. Ich drehte mich auch um und machte mir Sorgen, dass ich einen verrückten Fehler hatte, der nur unter ganz bestimmten Bedingungen auftauchte - ich wusste nicht einmal, wo ich anfangen sollte zu suchen.

Aber irgendetwas sagte mir, ich solle den Test erneut durchführen. Ich lief es und es ging vorbei. Ich habe ein Skript eingerichtet, um den Test fünfmal über Nacht auszuführen. Am Morgen waren alle 5 vergangen.

Das war also definitiv ein Cosmic Ray Bit Flip.

Vielleicht möchten Sie auch einen Blick auf fehlertolerante Hardware werfen.

Zum Beispiel baut Stratus Technology Wintel-Server namens ftServer, die zwei oder drei "Mainboards" im Sperrschritt hatten, und vergleicht das Ergebnis der Berechnungen. (Dies geschieht manchmal auch in Raumfahrzeugen).

Die Stratus-Server haben sich vom benutzerdefinierten Chipsatz zum Lockstep auf der Rückwandplatine entwickelt.

Ein sehr ähnliches (aber Software-) System ist der VMWare-Fehlertoleranz-Sperrschritt, der auf dem Hypervisor basiert.

Als Datenpunkt ist dies gerade bei unserem Build passiert:

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

Das sieht sehr stark nach einem kleinen Flip aus, der während einer Kompilierung zufällig an einer sehr wichtigen Stelle in einer Quelldatei auftritt.

Ich sage nicht unbedingt, dass dies ein "kosmischer Strahl" war, aber das Symptom stimmt überein.