Les rayons cosmiques: quelle est la probabilité qu'ils affectent un programme?
Une fois de plus, j'étais dans une revue de conception et j'ai rencontré l'affirmation selon laquelle la probabilité d'un scénario particulier était "moins que le risque de rayons cosmiques" affectant le programme, et j'ai réalisé que je n'avais pas la moindre idée de ce que cela la probabilité est.
"Depuis 2-128 est 1 sur 340282366920938463463374607431768211456, je pense que nous sommes en droit de tenter notre chance ici, même si ces calculs sont par un facteur de quelques milliards ... Nous sommes beaucoup plus à risque pour nous bousiller, I croyez."
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 90 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 est la suivante:
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 d'une défaillance. En outre, 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.
Apparemment, non négligeable. De cet article de New Scientist , une citation d'une demande de brevet Intel:
"Des pannes informatiques provoquées par les rayons cosmiques se sont produites et devraient augmenter avec la fréquence à mesure que les dispositifs (transistors, par exemple) diminuent en taille. Ce problème devrait devenir un limiteur majeur de la fiabilité informatique dans 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 intérieur du bureau .
Il existe plusieurs études sur les défaillances de la mémoire ECC dans de grandes batteries de serveurs, telles que des clusters du CERN et des 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 taux d'erreur corrigés par le code ECC (bitflips simples) sur les papiers, nous pouvons connaître le taux de corruption de mémoire silencieuse sur la mémoire non ECC.
Étude à grande échelle 2007 du CERN "Intégrité des données" : le fournisseur déclare " Taux d'erreur sur les bits de 10-12 pour leurs modules de mémoire "," , le taux d'erreur observé est inférieur de 4 ordres de grandeur aux attentes ". Pour les données - tâches intensives (8 Go/s en lecture mémoire), cela signifie qu’un retournement sur un bit peut se produire toutes les minutes (10-12 vendeurs) ou une fois tous les deux jours (10-16 BER).
L'article de 2009 de Google intitulé "Les erreurs de DRAM à l'état sauvage: une étude de terrain à grande échelle" indique qu'il peut exister jusqu'à 25 000-75 000 FIT par bit sur un bit ( échecs de temps par milliard d’heures ), ce qui correspond à 1 - 5 erreurs par heure pour 8 Go de RAM après mes calculs. Le papier dit la même chose: " signifie des taux d'erreur corrigibles de 2000 à 6000 par Go et par an ".
Rapport Sandia 2012 "Détection et correction de la corruption silencieuse des données pour le calcul haute performance à grande échelle" : "Les retournements binaires étaient jugés peu probables" jour pour plus de 75 000 DIMM ", même avec ECC. Et les erreurs sur un seul bit devraient être plus élevées.
Ainsi, si le programme a un jeu de données volumineux (plusieurs Go), ou a une vitesse de lecture ou d’écriture mémoire élevée (Go/s ou supérieure), et s’il dure 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 longues grappes fonctionnent sur des milliers de PC non ECC, comme BOINC, l’informatique en grille à l’échelle de l’Internet aura toujours des erreurs de mémoire mémoire ainsi que des erreurs silencieuses de disque et de réseau.
Et pour les plus grosses machines (10 000 serveurs), même avec une protection ECC contre les erreurs mono-bit, comme nous le voyons dans le rapport 2012 de Sandia, il peut y avoir des retournements double-bits chaque jour, vous n'aurez donc aucune chance d'exécuter en parallèle une taille réelle programme pendant plusieurs jours (sans point de contrôle régulier et sans redémarrage à partir du dernier bon point de contrôle en cas de double erreur). Les énormes machines obtiendront également des retournements de bits dans leurs caches et registres de processeurs (les déclencheurs architecturaux et internes de la puce, par exemple dans le chemin de données ALU), car ils ne sont pas tous 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 décédé plusieurs semaines plus tard. Il a commencé à donner beaucoup d'erreurs de mémoire. Ce que je reçois: l'ordinateur portable se bloque, Linux redémarre, exécute fsck, trouve les 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 exécuté environ 5 à 6), des erreurs sont toujours détectées sur le système de fichiers racine.
Wikipedia cite un étude d'IBM dans les années 90 suggérant que "les ordinateurs subissent généralement une erreur induite par les rayons cosmiques par 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 ce nombre très élevé, mais peut-être que la plupart des erreurs de mémoire induites par les rayons cosmiques ne posent aucun problème réel ou perceptible.
D'autre part, les gens qui parlent de probabilités lorsqu'il s'agit de scénarios logiciels n'ont généralement aucune idée de ce dont ils parlent.
Eh bien, les rayons cosmiques ont apparemment provoqué un dysfonctionnement de l'électronique dans les voitures Toyota, alors je dirais que la probabilité est très élevée :)
Les rayons cosmiques causent-ils vraiment des ennuis chez Toyota?
Avec ECC, vous pouvez corriger les erreurs sur 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 imbriquées dans des puces, de sorte qu'aucune cellule ne soit adjacente. Un événement de rayon cosmique qui affecte deux cellules entraînera donc deux erreurs corrigibles de 1 bit.
Sun déclare: (référence 816-5053-10 avril 2002)
En règle générale, les erreurs logicielles liées aux rayons cosmiques se produisent dans la mémoire DRAM à un taux d'environ 10 à 100 FIT/Mo (1 FIT = 1 défaillance d'un périphérique en un 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. La mémoire ECC correctement implémentée corrige les erreurs sur un bit et détecte les erreurs sur deux bits (arrêt du système si une telle erreur est détectée). Vous pouvez le voir à quelle fréquence les gens se plaignent de ce qui semble être un problème logiciel 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'un morceau de mémoire toujours défaillant, mais elle est pertinente pour la question plus générale de savoir à quel point vous devez faire confiance à votre mémoire pour qu'elle fonctionne correctement.
Une analyse basée sur une taille de résident de 20 Mo peut être appropriée pour des applications triviales, mais les grands systèmes ont systématiquement 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.
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 des systèmes au sol.
Par exemple, notez que les pièces Intel destinées aux applications "intégrées" ont tendance à ajouter ECC à la fiche technique. Il en 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 bloque un programme de temps en temps dans une lune bleue, l'utilisateur ne s'en soucie pas beaucoup. Le logiciel lui-même est de toute façon beaucoup moins fiable que le HW. Mais pour les SKU destinées à être utilisées dans des machines industrielles et dans l’automobile, la CCE est obligatoire. Depuis ici, nous nous attendons à ce que le logiciel soit beaucoup plus fiable et que les erreurs provenant de bouleversements aléatoires constituent un problème réel.
Les systèmes certifiés IEC 61508 et des normes similaires disposent généralement de tests de démarrage vérifiant que tous les RAM sont fonctionnels (aucun bit bloqué à zéro ou à un), ainsi que du traitement des erreurs à la sortie. Runtime qui tente de récupérer des erreurs détectées par ECC, et souvent également des tâches de nettoyage de la mémoire qui lisent et écrivent de la mémoire en continu afin de s’assurer que les erreurs éventuelles sont détectées.
Mais pour les logiciels grand public? Pas un gros problème. Pour un serveur de longue durée? Utilisez ECC et un gestionnaire d'erreur. Si une erreur non corrigible tue le noyau, qu’il en soit ainsi. Ou bien, vous devenez paranoïaque et utilisez un système redondant avec une exécution pas à pas, de sorte que si l'un des noyaux est corrompu, l'autre peut prendre le relais pendant le redémarrage du premier.
Si un programme est essentiel à la vie (il va tuer quelqu'un s'il échoue), il doit être écrit de manière à ce qu'il soit sécurisé ou récupère automatiquement d'un tel échec. Tous les autres programmes, YMMV.
Les Toyota sont un exemple typique. Dites ce que vous voulez à propos d’un câble d’accélérateur, mais ce n’est pas un logiciel .
Voir aussi http://en.wikipedia.org/wiki/Therac-25
J'ai déjà programmé des appareils destinés à voler dans l'espace, puis vous (supposément, personne ne m'a montré de papier à ce sujet, mais on disait que cela était de notoriété publique dans le monde des affaires), vous pouviez vous attendre à ce que les rayons cosmiques provoquent des erreurs tout le temps.
Les "événements de rayons cosmiques" sont considérés comme ayant une distribution uniforme dans de nombreuses réponses, cela peut ne pas toujours être vrai (c'est-à-dire les supernovas). Bien que "rayons cosmiques" par définition (du moins selon Wikipedia) vienne de espace extérieur , je pense qu’il est juste d’inclure également locales tempêtes solaires (alias éjection de masse coronale sous le même parapluie. Je pense que cela pourrait provoquer le retournement de plusieurs bits en un laps de temps très court, potentiellement assez pour être corrompu même la mémoire activée par ECC.
Il est bien connu que les tempêtes solaires peuvent causer des dégâts considérables dans les systèmes électriques (comme le panne de courant au Québec en mars 1989 ). Il est fort probable que les systèmes informatiques peuvent également être affectés.
Il y a environ 10 ans, j'étais assis à côté d'un autre gars, nous étions assis avec chacun de nos ordinateurs portables, c'était à une époque avec une tempête solaire assez "orageuse" (assis dans l'Arctique, nous pouvions l'observer indirectement - beaucoup d'aurores boréales à être vu). Soudain, au même moment, nos deux ordinateurs portables se sont écrasés. Il fonctionnait sous OS X, et moi sous Linux. Nous ne sommes pas habitués à ce que les ordinateurs portables tombent en panne - c'est une chose assez rare sous Linux et OS X. Des bogues logiciels courants peuvent être plus ou moins éliminés car nous utilisions différents systèmes d'exploitation (et cela ne s'est pas produit pendant un saut seconde). Je suis venu attribuer cet événement au "rayonnement cosmique".
Plus tard, le "rayonnement cosmique" est devenu une blague interne sur mon lieu de travail. Chaque fois que quelque chose se passe avec nos serveurs et que nous ne trouvons aucune explication, nous attribuons cette faute en plaisantant au "rayonnement cosmique". :-)
Le plus souvent, le bruit peut corrompre les données. Checksums sont utilisés pour lutter contre cela à plusieurs niveaux; dans un câble de données, il existe généralement un bit de parité qui voyage à côté des données. Ceci réduit considérablement la probabilité de corruption. Ensuite, aux niveaux d'analyse, les données non-sens sont généralement ignorées. Ainsi, même si une corruption dépasse le bit de parité ou d'autres sommes de contrôle, elle sera dans la plupart des cas ignorée.
En outre, 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 intervenants, il y a parfois un bit ou un octet qui est brouillé, et il est laissé au hasard qu'il s'agisse d'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 plante l'ordinateur (c'est une bonne chose, car l'ordinateur est protégé contre les dommages); mais le pire des cas, eh bien, je suis sûr que vous pouvez imaginer.
J'ai expérimenté ceci - Il n'est pas rare que les rayons cosmiques se 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 d'Adobe d'environ 500 Mo ou plus décompressés.
Après une compression fastidieuse et une 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é, m'inquiétant d'avoir un insecte fou qui n'apparaîtrait 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 configuré un script pour exécuter le test 5 fois en une nuit. Au matin, tous les 5 étaient passés.
Donc, c’était définitivement un rayon de rayons cosmiques.
Vous voudrez peut-être aussi jeter un coup d’œil sur le matériel tolérant aux pannes.
Par exemple, Stratus Technology construit des serveurs Wintel appelés ftServer qui ont 2 ou 3 "cartes mères" en verrouillage, comparant le résultat des calculs. (Cela se fait aussi parfois dans des véhicules spatiaux).
Les serveurs Stratus ont évolué depuis le jeu de puces personnalisé vers le verrouillage sur le fond de panier.
Un système très similaire (mais logiciel) est le blocage de VMWare Fault Tolerance basé sur l'hyperviseur.
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 fort à une bascule 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.