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

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 je me suis rendu compte que probabilité est

“Etant donné que 2 -128 est 1 sur 340282366920938463463374607431768211456, je pense que nous sums en droit de tenter notre chance ici, même si ces calculs ont été réduits d’un facteur de quelques milliards … Nous sums beaucoup plus exposés aux rayons cosmiques. bousculez-moi, 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?

    De Wikipedia :

    Des études réalisé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, soit 1,4 × 10 -15 par octet par seconde. Si votre programme fonctionne pendant 1 minute et occupe 20 Mo de RAM, la probabilité de défaillance serait de

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

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

    Apparemment, pas insignifiant. À partir de cet article de New Scientist , une citation d’une demande de brevet Intel:

    “Des accidents informatiques provoqués par les rayons cosmiques se sont produits et devraient s’accroître avec la fréquence à mesure que la taille des dispositifs (transistors, par exemple) diminuent en puces. Ce problème devrait devenir un obstacle majeur à la fiabilité informatique au cours de la prochaine décennie.”

    Vous pouvez lire le brevet complet ici .

    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, et d’autres de l’espace interne du bureau.

    Il existe plusieurs études sur les défaillances de la mémoire ECC sur de grandes batteries de serveurs telles que 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 y a beaucoup de postes de travail non-ECC (et de smartphones mobiles non-ECC). Si nous vérifions la présence de taux d’erreur corrigibles selon le format ECC (single bitflips), nous pouvons connaître le taux de corruption de mémoire silencieuse sur la mémoire non-ECC.

    • Etude à grande échelle 2007 du CERN “Intégrité des données” : les fournisseurs déclarent ” Taux d’erreur sur les bits de 10 -12 pour leurs modules de mémoire “, ” un taux d’erreur observé est de 4 ordres de grandeur inférieur aux prévisions “. Pour les tâches gourmandes en données (lecture de mémoire de 8 Go / s), cela signifie que le basculement sur un seul bit peut se produire toutes les minutes (10 à 12 BER de fournisseurs) ou une fois tous les deux jours (10 à 16 BER).

    • Le document de 2009 de Google intitulé “Erreurs de DRAM dans la nature: une étude de terrain à grande échelle” indique qu’il peut y avoir jusqu’à 25 000-75 000 FIT d’un bit par Mbit ( défaillances dans le 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: ” taux d’erreur corrigible moyen de 2000-6000 par Go par an “.

    • Rapport Sandia 2012 «Détection et correction de la corruption des données silencieuses pour le calcul haute performance à grande échelle» : les «renversements à double bit ont été jugés improbables», mais à un taux par jour de 75 000 DIMM avec ECC. Et les erreurs sur un seul bit devraient être plus élevées.

    Donc, si le programme possède un grand dataset (plusieurs Go), ou si le taux de lecture ou d’écriture (Go / s ou plus) est élevé, et qu’il fonctionne pendant plusieurs heures, on peut s’attendre à plusieurs retournements 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 grappes longues s’exécutent sur des milliers de PC non-ECC, comme le calcul de grid sur Internet à l’échelle de BOINC qui contient toujours des erreurs provenant des basculements de mémoire, ainsi que des erreurs silencieuses sur le disque et le réseau.

    Et pour les machines plus grandes (10 milliers de serveurs) même avec la protection ECC contre les erreurs sur un seul bit, comme nous le voyons dans le rapport Sandia 2012, il peut y avoir des renversements à deux bits chaque jour. programme pendant plusieurs jours (sans sharepoint contrôle régulier et redémarrage depuis le dernier sharepoint contrôle en cas de double erreur). Les énormes machines obtiendront également des bit-flips dans leurs caches et leurs registres cpu (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 pire si le module DRAM est mauvais. Par exemple, j’ai installé une nouvelle DRAM sur un ordinateur portable, qui est mort plusieurs semaines plus tard. Il a commencé à donner beaucoup d’erreurs de mémoire. Ce que je reçois: ordinateur portable se bloque, linux redémarre, lance fsck, trouve des erreurs sur le système de fichiers racine et dit qu’il veut faire redémarrer après avoir corrigé les erreurs. Mais à chaque redémarrage suivant (j’en ai fait environ 5 à 6), le système de fichiers racine contient toujours des erreurs.

    Wikipedia cite une étude réalisée par IBM dans les années 90, suggérant que «les ordinateurs subissent généralement une erreur induite par les rayons cosmiques par 256 Mo de RAM par mois». Malheureusement, la citation portait sur 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 matière de scénarios logiciels n’ont généralement aucune idée de ce dont ils parlent.

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

    Les rayons cosmiques sont-ils vraiment à l’origine des malheurs de Toyota?

    Avec ECC, vous pouvez corriger les erreurs de 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 intercalées sur des puces, de sorte qu’il n’y a pas deux cellules côte à côte. Un événement de rayon cosmique qui affecte deux cellules entraînera donc deux erreurs de 1 bit pouvant être corrigées.

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

    D’une manière générale, les erreurs logicielles de rayons cosmiques se produisent dans la mémoire DRAM à un débit d’environ 10 à 100 FIT / MB (1 FIT = 1 périphérique échoue en 1 milliard d’heures). Ainsi, un système doté de 10 Go de mémoire devrait afficher un événement ECC toutes les 1 000 à 10 000 heures et un système de 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.

    Les erreurs de mémoire sont réelles et la mémoire ECC aide. Correctement implémentée, la mémoire ECC corrigera les erreurs à un seul bit et détectera les erreurs à double bit (arrêt du système si une telle erreur est détectée). Vous pouvez le constater à quelle fréquence les utilisateurs se plaignent d’un problème logiciel résolu avec Memtest86 . découvrir la mauvaise mémoire. Bien sûr, une défaillance transitoire provoquée par un rayon cosmique est différente d’un élément de mémoire défaillant, mais elle concerne la question plus large de savoir à quel point vous devez faire confiance à votre mémoire pour fonctionner correctement.

    Une parsing basée sur une taille résidente de 20 Mo peut être appropriée pour les applications sortingviales, mais les systèmes de grande taille 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 être mort.

    Si un programme est critique pour la vie (il tue quelqu’un s’il échoue), il doit être écrit de manière à ce qu’il soit sécurisé ou qu’il se rétablisse automatiquement après un tel échec. Tous les autres programmes, YMMV.

    Les Toyota sont un exemple typique. Dites ce que vous voulez sur un câble d’accélérateur, mais ce n’est pas un logiciel.

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

    Une fois, j’ai programmé des appareils qui devaient voler dans l’espace, et puis vous (soi-disant, personne ne m’a jamais montré de papier à ce sujet, mais il était de notoriété publique) que les rayons cosmiques induiraient des erreurs tout le temps.

    C’est un problème réel, et c’est pourquoi la mémoire ECC est utilisée dans les serveurs et les systèmes intégrés. Et pourquoi les systèmes de vol sont différents de ceux basés au sol.

    Par exemple, notez que les composants Intel destinés aux applications “incorporées” ont tendance à append ECC à la fiche technique. Un Bay Trail pour une tablette en manque, 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 ne se soucie pas beaucoup. Le logiciel lui-même est beaucoup moins fiable que le matériel informatique. Mais pour les SKU destinés à être utilisés dans les machines indussortingelles et l’automobile, l’ECC est obligatoire. Comme ici, nous nous attendons à ce que le SW soit beaucoup plus fiable et que les erreurs provenant de perturbations aléatoires soient un véritable problème.

    Les systèmes certifiés selon la norme IEC 61508 et les normes similaires ont généralement des tests de démarrage qui vérifient que toute la RAM est fonctionnelle (pas de bits bloqués à zéro ou un), ainsi que la gestion des erreurs lors de l’exécution d’ECC. souvent aussi des tâches de nettoyage de la mémoire qui passent et lisent et écrivent de la mémoire en permanence pour s’assurer que toutes les erreurs se produisent.

    Mais pour les logiciels grand public? Pas un gros problème. Pour un serveur de longue durée? Utilisez ECC et un gestionnaire de pannes. Si une erreur irrécupérable tue le kernel, ainsi soit-il. Ou alors, vous devenez paranoïaque et utilisez un système redondant avec une exécution verrouillée, de sorte que si un kernel est corrompu, l’autre peut prendre le relais pendant le redémarrage du premier cœur.

    Plus souvent, le bruit peut corrompre les données. Les sums de contrôle sont utilisées pour lutter contre cela à plusieurs niveaux. Dans un câble de données, il existe généralement un bit de parité qui accompagne les données. Cela réduit considérablement la probabilité de corruption. Ensuite, lors de l’parsing des niveaux, les données non-sens sont généralement ignorées. Par conséquent, même si une certaine corruption dépassait le bit de parité ou d’autres sums de contrôle, elle serait dans la plupart des cas ignorée.

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

    Mais au bout du compte, comme les autres intervenants l’ont dit, il ya un bit ou un octet occasionnel qui est brouillé, et c’est un 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 nuire); mais dans le pire des cas, eh bien, je suis sûr que vous pouvez imaginer.

    Les “événements de rayons cosmiques” sont considérés comme ayant une dissortingbution uniforme dans beaucoup de réponses ici, ceci peut ne pas toujours être vrai (ie les supernovas). Bien que les «rayons cosmiques» par définition (du moins selon Wikipedia) viennent de l’espace, je pense qu’il est juste d’inclure également les tempêtes solaires locales ( éjection de masse coronale sous le même parapluie). un temps court, potentiellement suffisant pour corrompre même la mémoire compatible ECC.

    Il est bien connu que les tempêtes solaires peuvent causer des ravages dans les systèmes élecsortingques (comme la panne d’élecsortingcité survenue au Québec en mars 1989 ). Il est fort probable que les systèmes informatiques puissent également être affectés.

    Il y a 10 ans, j’étais assis juste à côté d’un autre, nous étions assis à côté de nos ordinateurs portables, c’était dans une période de temps assez “houleux” (assis dans l’Arctique, nous pouvions l’observer indirectement). être vu). Tout à coup, au même instant, nos deux ordinateurs portables se sont écrasés. Il utilisait OS X et je travaillais sous Linux. Aucun de nous n’est habitué à ce que les ordinateurs portables se brisent – c’est une chose assez rare sur Linux et OS X. Les bogues logiciels courants peuvent plus ou moins être écartés puisque nous utilisions des systèmes d’exploitation différents (et cela n’a pas été le cas seconde). Je suis venu pour atsortingbuer cet événement à “rayonnement cosmique”.

    Plus tard, le “rayonnement cosmique” est devenu une blague interne sur mon lieu de travail. Chaque fois que quelque chose arrive avec nos serveurs et que nous ne trouvons aucune explication à cela, nous atsortingbuons la faute à la “radiation cosmique”. 🙂

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

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

    Après une opération de compression fastidieuse et une parsing de décompression pour tester l’intégrité, FC / B a montré un octet différent.

    Dans cet octet, le MSB avait basculé. Je me suis aussi retourné, craignant que je n’aie un bug fou qui ne ferait surface que dans des conditions très précises – je ne savais même pas par où commencer.

    Mais quelque chose m’a dit de relancer le test. Je l’ai couru et c’est passé. J’ai configuré un script pour exécuter le test 5 fois par jour. Le matin, tous les 5 étaient passés.

    C’était donc certainement un coup de rayon cosmique.

    Vous pouvez également consulter le matériel tolérant aux pannes.

    Par exemple, Stratus Technology construit des serveurs Wintel appelés ftServer qui comportaient 2 ou 3 “Mainboards” en mode pas-à-pas, en comparant le résultat des calculs. (cela se fait aussi dans les véhicules spatiaux parfois).

    Les serveurs Stratus ont évolué du chipset personnalisé à celui du backplane.

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

    En tant que sharepoint données, cela s’est produit 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 beaucoup à un flip survient lors d’une compilation, à un endroit très significatif dans un fichier source par hasard.

    Je ne dis pas nécessairement que c’était un “rayon cosmique”, mais les symptômes correspondent.