Rayons cosmiques: quelle est la probabilité qu'ils affectent un programme?

546

Encore une fois, j'étais dans une revue de conception, et j'ai rencontré l'affirmation selon laquelle la probabilité d'un scénario particulier était "inférieure au risque de rayons cosmiques" affectant le programme, et il m'est venu à l'esprit que je n'avais pas la moindre idée de ce que cela la probabilité est.

"Puisque 2 ^-128 est 1 sur 340282366920938463463374607431768211456, je pense que nous sommes justifiés de tenter notre chance ici, même si ces calculs sont faussés par un facteur de quelques milliards ... Nous sommes beaucoup plus à risque pour les rayons cosmiques de nous bousiller, je crois. "

Ce programmeur est-il correct? Quelle est la probabilité qu'un rayon cosmique frappe un ordinateur et affecte l'exécution du programme?

— Mark Harrison
source

42

"Gagner des loteries: quelle est la probabilité qu'elles affectent un programme?"

— kennytm

27

Cela dépend en partie de l'endroit où le programme est exécuté et de la façon dont il est protégé. Sur Terre, le flux de rayons cosmiques est beaucoup plus faible que dans l'espace lointain, ou même près de l'orbite terrestre. Le télescope spatial Hubble, par exemple, produit des images brutes criblées de traces de rayons cosmiques.

— Adam Hollidge

89

Cela signifie-t-il qu'à partir de maintenant, lorsque quelqu'un posera des questions sur les finallyblocs, nous devrons le qualifier de «s'exécute toujours sauf si le programme se termine ou s'il est frappé par un rayon cosmique»?

— skaffman

72

En travaillant sur un prototype de détecteur de particules il y a des années, je l'ai programmé pour imprimer "aïe!" chaque fois qu'il a été touché par un rayon cosmique. Bons moments ...

— Beta

8

L'une des questions les plus intéressantes que j'ai lues ici depuis un moment. Une véritable révélation. Comptez sur moi pour rouvrir.

— Agnel Kurian

308

De Wikipédia :

Des études effectuées par IBM dans les années 1990 suggèrent que les ordinateurs subissent généralement une erreur induite par les rayons cosmiques par 256 mégaoctets de RAM par mois. ^[15]

Cela signifie une probabilité de 3,7 × 10 ^-9 par octet par mois, ou 1,4 × 10 ^-15 par octet par seconde. Si votre programme dure 1 minute et occupe 20 Mo de RAM, la probabilité d'échec serait

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

La vérification des erreurs peut aider à réduire les conséquences de l'échec. De plus, en raison de la taille plus compacte des puces, comme l'a commenté Joe, le taux d'échec pourrait être différent de ce qu'il était il y a 20 ans.

— kennytm
source

10

Plus important encore, la taille de la puce pour les processeurs en 1995 était d'environ 0,35 µm ou 350 nm. Il fait maintenant 1/10 de cette taille à 35 nm.

— Joe Koberg

18

Est-il possible qu'au lieu de réduire le risque, une taille réduite augmente le risque car il faudrait moins d'énergie pour changer l'état de chaque bit?

— Robert

63

Une taille réduite augmente définitivement le risque. Les processeurs renforcés pour les véhicules spatiaux utilisent de très grandes tailles pour éviter les effets des rayons cosmiques.

— Joe Koberg

22

Pas seulement les rayons cosmiques, les isotopes radioactifs dans les matériaux utilisés dans la puce sont un problème beaucoup plus important. Les fabricants se donnent beaucoup de mal pour s'assurer que le silicium, la soudure, l'encapsulation, etc. ne contiennent aucun émetteur alpha ou bêta.

— Martin Beckett

14

Hou la la! Cela signifie qu'environ 1 octet sur mon PC est corrompu tous les deux jours.

— Stefan Monov

91

Apparemment, ce n'est pas anodin. De cet article du New Scientist , une citation d'une demande de brevet Intel:

"Des accidents informatiques provoqués par les rayons cosmiques se sont produits et devraient augmenter avec la fréquence à mesure que les dispositifs (par exemple, les transistors) diminuent de taille dans les puces. Ce problème devrait devenir un limiteur majeur de la fiabilité des ordinateurs au cours de la prochaine décennie."

Vous pouvez lire le brevet complet ici .

— ire_and_curses
source

7

Pourquoi augmentent-ils avec une diminution de la taille de la puce? Il est certain qu'un objet plus petit est moins susceptible d'être touché par un rayon (c'est-à-dire de comparer le fait de lancer une balle de tennis contre un mur à le lancer avec un tampon)

— Jonathan.

7

Parce que la taille des composants diminue, ils deviennent beaucoup plus sensibles aux coups de rayons cosmiques.

— ire_and_curses

4

Oui, plus petit est moins susceptible d'être touché, mais plus probable que le coup affectera l'état.

— John Hascall

2

@ire_and_curses [citation nécessaire]

— Anko

8

@Anko - C'est assez évident. À mesure qu'un composant donné devient plus petit, il a besoin de moins de tension et de charge pour régler un peu. Cela le rend plus sensible aux explosions d'énergie de l'espace. Cependant, voici une citation pour vous: à mesure que les dispositifs de mémoire LSI deviennent plus petits, ils deviennent plus sensibles aux défaillances douces induites par le rayonnement nucléaire.

— ire_and_curses

55

Remarque: cette réponse ne concerne pas la physique, mais les erreurs de mémoire silencieuses avec les modules de mémoire non ECC. Certaines erreurs peuvent provenir de l'espace extra-atmosphérique et d'autres - de l'espace interne du bureau.

Il existe plusieurs études sur les défaillances de la mémoire ECC dans les grandes batteries de serveurs comme les clusters CERN et les centres de données Google. Le matériel de classe serveur avec ECC peut détecter et corriger toutes les erreurs sur un seul bit et détecter de nombreuses erreurs sur plusieurs bits.

Nous pouvons supposer qu'il existe de nombreux ordinateurs de bureau non ECC (et smartphones mobiles non ECC). Si nous vérifions les papiers pour les taux d'erreur corrigeables ECC (bitflips simples), nous pouvons connaître le taux de corruption de mémoire silencieuse sur la mémoire non ECC.

Étude à grande échelle du CERN 2007 "Intégrité des données" : les fournisseurs déclarent "un taux d'erreur binaire de 10 à ¹² pour leurs modules de mémoire ", " un taux d'erreur observé est de 4 ordres de grandeur inférieur à celui attendu ". Pour les tâches gourmandes en données (8 Go / s de lecture de mémoire), cela signifie que le basculement sur un seul bit peut se produire toutes les minutes ( BER de 10 à ¹² fournisseurs) ou une fois tous les deux jours ( BER de 10 à ¹⁶ ).
Le document de 2009 de Google intitulé "Erreurs DRAM dans la nature: une étude de terrain à grande échelle" indique qu'il peut y avoir jusqu'à 25 000 à 75 000 FIT 1 bit par Mbit ( échecs de temps par milliard d'heures ), ce qui équivaut à 1 - 5 bits. erreurs par heure pour 8 Go de RAM après mes calculs. Le papier dit la même chose: " des taux d'erreur corrigibles moyens de 2000–6000 par Go par an ".
2012 Sandia report "Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing" : "les flips à double bit étaient jugés improbables" mais à l'ORNL dense Cray XT5 ils sont "au rythme de un par jour pour 75 000+ DIMM" même avec ECC. Et les erreurs sur un seul bit devraient être plus élevées.

Donc, si le programme a un grand ensemble de données (plusieurs Go), ou a un taux élevé de lecture ou d'écriture en mémoire (Go / s ou plus), et qu'il s'exécute pendant plusieurs heures, alors nous pouvons nous attendre à plusieurs flips de bits silencieux sur le matériel de bureau. Ce taux n'est pas détectable par memtest, et les modules DRAM sont bons.

Les clusters longs s'exécutent sur des milliers de PC non ECC, comme l'informatique de grille à l'échelle de BOINC sur Internet, il y aura toujours des erreurs de bit-flips de mémoire ainsi que des erreurs silencieuses de disque et de réseau.

Et pour les machines plus grandes (10 000 serveurs), même avec une protection ECC contre les erreurs sur un seul bit, comme nous le voyons dans le rapport 2012 de Sandia, il peut y avoir des retournements sur deux bits tous les jours, vous n'aurez donc aucune chance d'exécuter en parallèle pleine taille programme pendant plusieurs jours (sans point de contrôle régulier et redémarrage à partir du dernier bon point de contrôle en cas de double erreur). Les énormes machines obtiendront également des bit-flips dans leurs caches et registres de processeur (à la fois les déclencheurs architecturaux et internes de la puce, par exemple dans le chemin de données ALU), car tous ne sont pas protégés par ECC.

PS: Les choses seront bien pires si le module DRAM est mauvais. Par exemple, j'ai installé une nouvelle DRAM dans un ordinateur portable, qui est mort plusieurs semaines plus tard. Cela a commencé à donner beaucoup d'erreurs de mémoire. Ce que j'obtiens: l'ordinateur portable se bloque, Linux redémarre, exécute fsck, trouve des erreurs sur le système de fichiers racine et dit qu'il veut redémarrer après avoir corrigé les erreurs. Mais à chaque redémarrage suivant (j'en ai fait environ 5-6), il y a toujours des erreurs sur le système de fichiers racine.

— osgx
source

9

Matériel supplémentaire de BH 2011: «Bitsquatting. Détournement de DNS sans exploitation» media.blackhat.com/bh-us-11/Dinaburg/… répertorie les DRAM multi-GB modernes pour avoir environ 10000-30000 FIT / Mbit (moins de 100 heures entre erreurs pour chaque 128 Mo). Le document répertorie également des articles qui concluent que la plupart des erreurs logicielles sont dues au rayonnement, presque tous les cas - des rayons cosmiques et certains cas d'émetteurs alpha à l'intérieur du PC. Les auteurs de BH ont expérimenté et obtenu 50000 accès aux domaines, ayant 1 bit changé depuis les sites populaires

— osgx

Félicitations pour avoir ajouté des études plus récentes ici. Compte tenu de la dynamique du vote des OS et de leur accumulation dans le temps, il est hélas difficile d'avoir une présentation à jour sur ce sujet (ici).

— Fizz

Nous avons eu un problème similaire. Nous n'avons fait aucune étude exacte, mais nous avons eu pas mal de vidages sur incident avec des retournements de bits visibles. Nous avons vérifié ces bit flips et il s'est avéré qu'ils étaient dans la section code. Nous avons comparé ce qui devrait être là et cela ne ressemblait pas à une modification délibérée (c'est-à-dire que les instructions résultantes n'avaient pas beaucoup de sens). En fin de compte, nous avions une application simple, qui comparait les vidages sur incident aux versions publiées (archivées) et filtrait ces cas. Fait intéressant, je pense que la plupart de ces cas venaient d'Iran, d'Arabie et je pense qu'un autre pays d'Amérique du Sud (je ne m'en souviens pas maintenant).

— GiM

2

Dans l'article de Google, il semble plus que la RAM soit mauvaise. Environ un tiers des machines et plus de 8% des modules DIMM de notre flotte ont vu au moins une erreur corrigible par an. Nos taux d'erreurs corrigibles par module DIMM se traduisent par une moyenne de 25 000 à 75 000 FIT (défaillances dans le temps par milliard d'heures de fonctionnement) par Mbit et une plage FIT médiane de 778 à 25 000 par Mbit (médiane pour les modules DIMM avec erreurs), tandis que les études précédentes indiquent 200-5 000 FIT par Mbit. Le nombre d'erreurs corrigibles par module DIMM est très variable, certains modules DIMM subissant un nombre important d'erreurs par rapport à d'autres.

— vartec

31

Wikipedia cite une étude d'IBM dans les années 90 suggérant que «les ordinateurs subissent généralement une erreur induite par les rayons cosmiques pour 256 mégaoctets de RAM par mois». Malheureusement, la citation concernait un article de Scientific American, qui ne donnait aucune autre référence. Personnellement, je trouve que ce nombre est très élevé, mais peut-être que la plupart des erreurs de mémoire induites par les rayons cosmiques ne causent aucun problème réel ou notable.

D'un autre côté, les gens qui parlent de probabilités en ce qui concerne les scénarios logiciels n'ont généralement aucune idée de ce dont ils parlent.

— JesperE
source

7

La probabilité qu'un bit soit inversé doit être multipliée par la probabilité que le bit ait un effet notable sur le programme. Je suppose que la deuxième probabilité est beaucoup plus faible que vous ne le pensez.

— Mark Ransom

2

@Mark: Les programmes informatiques classiques ne disposent pas de ce type de tolérance aux pannes intégré. Une erreur sur un seul bit dans le code du programme entraînera plus que probablement le programme, si le code cassé est exécuté.

— Robert Harvey

75

Oui, mais la plupart de la mémoire contient des données, où le flip ne sera pas aussi visible.

— zoul

34

@zoul. lol à 'visiblp', mais si e = 1100101 et p = 1110000 alors vous êtes la malheureuse victime de flips 3 bits!

— PaulG

10

@Paul: ou un doigt blip.

— mpen

30

Eh bien, les rayons cosmiques ont apparemment causé un dysfonctionnement de l'électronique dans les voitures Toyota, donc je dirais que la probabilité est très élevée :)

Les rayons cosmiques causent-ils vraiment des problèmes à Toyota?

— Kevin Crowell
source

23

"Les régulateurs fédéraux étudient si l'accélération soudaine de Toyotas est liée aux rayons cosmiques." C'est pourquoi vous ne devriez jamais donner aux régulateurs fédéraux le pouvoir sur votre vie.

13

Je suppose que la théorie ici est que les rayons cosmiques renversent des bits dans des cerveaux plus anciens, ce qui les fait mal fonctionner et appuyer sur la mauvaise pédale.

— Knox

16

"Apparemment"? Je dirais que c'est une supposition sauvage à ce stade. Ma propre supposition est que ce phénomène est le résultat de ce vieux cauchemar des systèmes embarqués (en fait les systèmes informatiques les plus complexes) - la condition de concurrence.

— Michael Burr

7

@Knox: Sortez votre vieux chapeau de papier d' aluminium, il est utile!

3

Ce n'est peut-être pas une blague. J'ai déjà vu des trucs vraiment étranges comme ça. Pas aussi rare que la plupart des gens le pensent.

— Brian Knoblauch

25

Avec ECC, vous pouvez corriger les erreurs 1 bit des rayons cosmiques. Afin d'éviter les 10% de cas où les rayons cosmiques entraînent des erreurs de 2 bits, les cellules ECC sont généralement entrelacées sur des puces, de sorte qu'il n'y a pas deux cellules l'une à côté de l'autre. Un événement de rayons cosmiques qui affecte deux cellules entraînera donc deux erreurs 1 bit corrigibles.

Sun déclare: (Pièce n ° 816-5053-10 avril 2002)

De manière générale, les erreurs logicielles des rayons cosmiques se produisent dans la mémoire DRAM à un taux de ~ 10 à 100 FIT / Mo (1 FIT = 1 appareil tombe en panne en 1 milliard d'heures). Ainsi, un système avec 10 Go de mémoire devrait afficher un événement ECC toutes les 1 000 à 10 000 heures, et un système avec 100 Go afficherait un événement toutes les 100 à 1 000 heures. Cependant, il s'agit d'une estimation approximative qui changera en fonction des effets décrits ci-dessus.

— eckes
source

17

Les erreurs de mémoire sont réelles et la mémoire ECC aide. La mémoire ECC correctement mis en œuvre corrigera les erreurs individuelles de bits et détecter doubles erreurs binaires (arrêt du système si une telle erreur est détectée.) Vous pouvez voir cela de la façon dont régulièrement les gens se plaignent de ce qui semble être un problème de logiciel qui est résolu en exécutant Memtest86 et découvrir une mauvaise mémoire. Bien sûr, une défaillance transitoire causée par un rayon cosmique est différente d'une mémoire défaillante, mais elle est pertinente pour la question plus large de savoir à quel point vous devez faire confiance à votre mémoire pour fonctionner correctement.

Une analyse basée sur une taille résidente de 20 Mo peut être appropriée pour des applications triviales, mais les grands systèmes ont régulièrement plusieurs serveurs avec de grandes mémoires principales.

Lien intéressant: http://cr.yp.to/hardware/ecc.html

Le lien Corsair dans la page semble malheureusement mort.

— janm
source

Les bitflips des rayons cosmiques peuvent ne pas être uniformément distribués, en particulier si nous incluons les tempêtes solaires sous le parapluie «événements de rayons cosmiques». Si vous avez obtenu deux bitflips ou plus dans le même octet, l'ECC typique ne pourra pas corriger l'erreur.

— tobixen

@tobixen Détecter une erreur double bit est préférable à continuer à s'exécuter avec de mauvaises données. La prochaine étape après ECC est Chipkill avec la mise en miroir DIMM ...

— janm

13

C'est un vrai problème, et c'est pourquoi la mémoire ECC est utilisée dans les serveurs et les systèmes embarqués. Et pourquoi les systèmes de vol sont différents de ceux au sol.

Par exemple, notez que les pièces Intel destinées aux applications "embarquées" ont tendance à ajouter ECC à la fiche technique. Il manque un Bay Trail pour une tablette, car cela rendrait la mémoire un peu plus chère et peut-être plus lente. Et si une tablette plante un programme à chaque fois dans une lune bleue, l'utilisateur s'en fiche peu. Le logiciel lui-même est de loin beaucoup moins fiable que le HW. Mais pour les références destinées à être utilisées dans les machines industrielles et l'automobile, l'ECC est obligatoire. Depuis ici, nous nous attendons à ce que le SW soit beaucoup plus fiable, et les erreurs de bouleversements aléatoires seraient un vrai problème.

Les systèmes certifiés CEI 61508 et normes similaires ont généralement à la fois des tests de démarrage qui vérifient que toute la RAM est fonctionnelle (aucun bit bloqué à zéro ou un), ainsi qu'une gestion des erreurs lors de l'exécution qui tente de récupérer des erreurs détectées par ECC, et souvent aussi des tâches de nettoyage de la mémoire qui passent par et lisent et écrivent la mémoire en continu pour s'assurer que toutes les erreurs qui se produisent sont remarquées.

Mais pour les logiciels PC traditionnels? Pas grave. Pour un serveur à longue durée de vie? Utilisez ECC et un gestionnaire de pannes. Si une erreur non corrigible tue le noyau, qu'il en soit ainsi. Ou vous devenez paranoïaque et utilisez un système redondant avec exécution de verrouillage afin que si un cœur est corrompu, l'autre puisse prendre le relais pendant que le premier cœur redémarre.

— jakobengblom2
source

Les bitflips des rayons cosmiques peuvent ne pas être uniformément distribués, en particulier si nous incluons les tempêtes solaires sous le parapluie «événements de rayons cosmiques». Une salve soudaine peut provoquer plusieurs bitflips dans un octet, et les algorithmes ECC ne pourront pas corriger une panne.

— tobixen

12

Si un programme est vital (il tuera quelqu'un en cas d'échec), il doit être écrit de telle sorte qu'il soit à sécurité intégrée ou qu'il récupère automatiquement après une telle défaillance. Tous les autres programmes, YMMV.

Les Toyotas en sont un exemple. Dites ce que vous voulez d'un câble d'accélérateur, mais ce n'est pas un logiciel.

Voir aussi http://en.wikipedia.org/wiki/Therac-25

— Robert Harvey
source

Peu importe le logiciel pour les gaz. Les capteurs et le câblage des gaz sont le point faible. Mon capteur de position de papillon Mitsubishi est tombé sur un générateur de nombres aléatoires ... Aucune accélération involontaire, mais cela n'a certainement rien fait de bon pour le mélange de carburant!

— Brian Knoblauch

3

@Brian: Un bon logiciel aurait compris que les points de données étaient discontinus et concluait que les données étaient mauvaises.

— Robert Harvey

..et puis quoi ... De bonnes données sont nécessaires. Savoir que c'est mauvais n'aide en rien. Pas quelque chose que vous pouvez contourner comme par magie.

— Brian Knoblauch

3

@Brian: Eh bien, pour commencer, vous pouvez prendre des mesures correctives en sachant que vos données sont incorrectes. Vous pouvez arrêter d'accélérer, par exemple.

— Robert Harvey

Oui, vous pouvez (et devriez) utiliser les données de cheksum. Meilleur de bout en bout. Cependant, cela ne fait que réduire les risques de corruption. Imaginez que votre instruction "est-ce valide" obtient-elle le bit corrompu dans la mémoire ou le registre CPU juste au moment où vous souhaitez vous connecter au gestionnaire d'erreurs.

— eckes

11

J'ai déjà programmé des appareils qui devaient voler dans l'espace, puis vous (soi-disant, personne ne m'a jamais montré de papier à ce sujet, mais il était connu de tous), les rayons cosmiques pouvaient induire des erreurs tout le temps.

— erikkallen
source

8

Au-dessus de l'atmosphère, deux choses se produisent: 1) le flux total est plus élevé 2) beaucoup plus se présente sous la forme de particules lourdes et très énergétiques (avec suffisamment d'énergie pour retourner un peu emballées dans un petit espace).

— dmckee --- chaton ex-modérateur

En ce qui concerne les références, il existe des livres (par exemple, books.google.com/books?hl=en&lr=&id=Er5_rzW0q3MC ), des conférences (par exemple, radecs2015.org , seemapld.org et autres), et des articles à gogo sur ce sujet . Les rayons cosmiques ne sont pas une blague en aérospatiale. Ils sont l'une des principales raisons pour lesquelles de nombreux engins spatiaux utilisent des ordinateurs durcis par rad, dont la plupart ont la puissance de traitement d'un four grille-pain intelligent moderne.

— David Hammen

8

les "événements de rayons cosmiques" sont considérés comme ayant une distribution uniforme dans de nombreuses réponses ici, cela peut ne pas toujours être vrai (c'est-à-dire les supernovas). Bien que les «rayons cosmiques» par définition (du moins selon Wikipedia) proviennent de l' espace extra- atmosphérique, je pense qu'il est juste d'inclure également les tempêtes solaires locales (alias éjection de masse coronale sous le même parapluie. Je pense que cela pourrait faire basculer plusieurs bits dans un court laps de temps, potentiellement suffisant pour corrompre même la mémoire compatible ECC.

Il est bien connu que les tempêtes solaires peuvent causer des ravages aux systèmes électriques (comme la panne de courant de Québec en mars 1989 ). Il est fort probable que les systèmes informatiques puissent également être affectés.

Il y a une dizaine d'années, j'étais assis juste à côté d'un autre gars, nous étions assis avec chacun nos ordinateurs portables, c'était dans une période de temps solaire assez "orageux" (assis dans l'Arctique, nous pouvions l'observer indirectement - beaucoup d'aurores boréales à être vu). Soudain - au même instant - nos deux ordinateurs portables se sont écrasés. Il exécutait OS X, et je courais Linux. Aucun de nous n'est habitué au plantage des ordinateurs portables - c'est une chose assez rare sur Linux et OS X. Les bogues logiciels courants peuvent plus ou moins être écartés car nous fonctionnions sur différents OS (et cela ne s'est pas produit lors d'un saut seconde). Je suis venu attribuer cet événement au "rayonnement cosmique".

Plus tard, le "rayonnement cosmique" est devenu une plaisanterie interne sur mon lieu de travail. Chaque fois que quelque chose se produit avec nos serveurs et que nous ne pouvons trouver aucune explication, nous attribuons en plaisantant la faute au "rayonnement cosmique". :-)

— tobixen
source

7

Plus souvent, le bruit peut corrompre les données. Les sommes de contrôle sont utilisées pour lutter contre cela à plusieurs niveaux; dans un câble de données, il y a généralement un bit de parité qui parcourt les données. Cela réduit considérablement la probabilité de corruption. Ensuite, au niveau de l'analyse, les données non-sens sont généralement ignorées, donc même si une corruption dépassait le bit de parité ou d'autres sommes de contrôle, elle serait dans la plupart des cas ignorée.

De plus, certains composants sont blindés électriquement pour bloquer le bruit (probablement pas les rayons cosmiques je suppose).

Mais en fin de compte, comme l'ont dit les autres répondants, il y a le bit ou l'octet occasionnel qui est brouillé, et c'est laissé au hasard que ce soit un octet significatif ou non. Dans le meilleur des cas, un rayon cosmique brouille l'un des bits vides et n'a absolument aucun effet, ou bloque l'ordinateur (c'est une bonne chose, car l'ordinateur est empêché de faire du mal); mais le pire des cas, eh bien, je suis sûr que vous pouvez imaginer.

— Ricket
source

Les bitflips des rayons cosmiques peuvent ne pas être uniformément distribués, en particulier si nous incluons les tempêtes solaires sous le parapluie «événements de rayons cosmiques». Si vous avez obtenu deux bitflips dans le même octet, la vérification du bit de parité échouera. Plusieurs bitflips et algorithmes ECC ne seront probablement pas en mesure de corriger une panne.

— tobixen

5

J'ai vécu cela - Il n'est pas rare que les rayons cosmiques retournent un peu, mais il est très peu probable qu'une personne observe cela.

Je travaillais sur un outil de compression pour un programme d'installation en 2004. Mes données de test étaient des fichiers d'installation Adobe d'environ 500 Mo ou plus décompressés.

Après un cycle de compression fastidieux et un cycle de décompression pour tester l'intégrité, FC / B a montré un octet différent.

Dans cet octet, le MSB avait basculé. J'ai également renversé, craignant d'avoir un bug fou qui ne ferait surface que dans des conditions très spécifiques - je ne savais même pas par où commencer.

Mais quelque chose m'a dit de refaire le test. Je l'ai couru et c'est passé. J'ai mis en place un script pour exécuter le test 5 fois pendant la nuit. Le matin, tous les 5 étaient passés.

C'était donc définitivement un retournement de bits de rayons cosmiques.

— rep_movsd
source

Absolument? Ne pourrait-il pas s'agir d'une variable non initialisée qui n'a jamais obtenu une mauvaise valeur initiale dans les tests suivants?

— doug65536

Je compile toujours avec W3 ou W4 sur VS - Aussi Rational Purify, il n'y avait pas de bugs de ce genre.

— rep_movsd

Ah, désolé, je ne savais pas que ces options de compilation et Rational Purify étaient absolument infaillibles. =)

— doug65536

Étant donné que le code a ensuite été mis en production et compressé et décompressé des centaines de Go correctement, il n'y avait aucun signe d'un bogue similaire.

— rep_movsd

4

Vous pouvez également consulter le matériel à tolérance de panne.

Par exemple, Stratus Technology construit des serveurs Wintel appelés ftServer qui avaient 2 ou 3 "cartes mères" en étape de verrouillage, comparant le résultat des calculs. (cela se fait aussi parfois dans les véhicules spatiaux).

Les serveurs Stratus sont passés du chipset personnalisé au verrouillage sur le fond de panier.

Un système très similaire (mais logiciel) est le lockstep VMWare Fault Tolerance basé sur l'hyperviseur.

— eckes
source

4

En tant que point de données, cela vient de se produire sur notre build:

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

Cela ressemble très fortement à un petit retournement qui se produit lors d'une compilation, à un endroit très important dans un fichier source par hasard.

Je ne dis pas nécessairement que c'était un "rayon cosmique", mais le symptôme correspond.

— dascandy
source