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

apparemment, pas insignifiant. De ce nouvel article scientifique , une citation D'une demande de brevet Intel:

"rayons Cosmiques induite par ordinateur accidents ont eu lieu et sont appelés à augmenter avec la fréquence comme des périphériques (par exemple, des transistors) la diminution de la taille des puces. Ce problème devrait devenir l'un des principaux facteurs limitant la fiabilité des ordinateurs au cours de la prochaine décennie. "

vous pouvez lire le brevet complet ici .

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

il existe plusieurs études sur les échecs de mémoire ECC sur les grandes fermes de serveurs comme CERN clusters et Google datacenters. Le matériel de classe serveur avec ECC peut détecter et corriger toutes les erreurs de bits simples, et détecter de nombreuses erreurs multi-bits.

nous pouvons supposer qu'il y a beaucoup d'ordinateurs de bureau non-ECC (et les smartphones mobiles non-ECC). Si nous vérifions les papiers pour les taux d'erreur ECC-correctable (bitflips simples), nous pouvons connaître taux de corruption mémoire silencieuse sur la mémoire NON-ECC.

• à Grande échelle CERN étude de 2007 "l'intégrité des Données" : les fournisseurs qui déclare " Taux d'Erreur de 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 à forte intensité de données (8 Go/s de lecture de mémoire) cela signifie qu'un basculement d'un bit peut se produire à chaque minute (10 ^-12 ber vendeurs) ou une fois dans deux jours (10 ^-16 BER).

• 2009 Google papier "erreurs de DRAM dans la nature: une étude de terrain à grande échelle" dit qu'il peut y avoir jusqu'à 25000-75000 ajustement d'un bit par Mbit ( échecs dans le temps par milliard d'heures ), qui est égal à 1 - 5 erreurs de bits par heure pour 8 Go de mémoire vive après mes calculs. Le papier dit la même chose:" moyenne taux d'erreur correctable de 2000-6000 par Go par an ".

• 2012 Sandia report "détection et Correction de corruption de données silencieuses pour le calcul haute Performance à grande échelle " :" double bit les flips ont été jugés peu probables" mais à ORNL's dense Cray XT5 ils sont "à un taux d'un par jour pour 75.000+ DIMMs" même avec ECC. Et les erreurs simples devraient être plus élevées.

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

long cluster fonctionne sur des milliers de PC non-ECC, comme BOINC Internet-wide grid computing aura toujours des erreurs de mémoire bit-flips et aussi de disque et des erreurs silencieuses réseau.

et pour les machines plus grandes (10 milliers de serveurs), même avec la protection ECC contre les erreurs mono-bit, comme nous le voyons dans le rapport 2012 de Sandia, il peut y avoir des sauts à double bit chaque jour, de sorte que vous n'aurez aucune chance d'exécuter le programme parallèle pleine taille pendant plusieurs jours (sans checkpointing régulier et redémarrage du dernier bon checkpoint en cas de double erreur). Les énormes machines auront aussi des sauts de bit-F dans leurs caches et leurs registres cpu (déclencheurs architecturaux et internes de chip par exemple dans le datapath D'ALU), parce que 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é un nouveau DRAM dans un ordinateur portable, qui est mort plusieurs semaines plus tard. Il a commencé à donner beaucoup d'erreurs de mémoire. Ce que j'obtiens: ordinateur portable raccroche, linux redémarre, exécute fsck, trouve des erreurs sur le système de fichiers racine et dit qu'il veut faire redémarrage après avoir corrigé les erreurs. Mais à chaque redémarrage suivant (j'ai fait environ 5-6) il y a encore des erreurs sur le système de fichiers racine.

Wikipedia cite une étude par IBM dans les années 90 suggérant que " les ordinateurs éprouvent généralement environ une erreur induite par les rayons cosmiques pour 256 mégaoctets de mémoire vive par mois."Malheureusement, la citation était à un article dans Scientific American, qui n'a pas donné d'autres références. 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 pas de problèmes réels ou perceptibles.

d'un autre côté, 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 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 chez Toyota?

avec ECC vous pouvez corriger les erreurs de 1 bit de rayons cosmiques. Afin d'éviter les 10% de cas où les rayons cosmiques provoquent des erreurs de 2 bits, les cellules ECC sont généralement intercalées sur des puces, de sorte qu'aucune cellule n'est adjacente. Un événement de rayonnement cosmique qui affecte deux cellules entraînera donc deux erreurs 1bit pouvant être corrigées.

Soleil états: (n ° de Pièce 816-5053-10 avril 2002)

en général, les erreurs de rayons cosmiques se produisent dans la mémoire DRAM à un taux de ~10 à 100 TRG / Mo (1 trg = 1 défaillance de l'appareil en 1 milliard d'heures). Ainsi un système avec 10 Go de mémoire devrait montrer un événement ECC tous les 1.000 à 10.000 heures, et un système avec 100 Go montrerait un événement chaque 100 à 1000 heures. Cependant, c'est une estimation approximative qui changer 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 corrigera les erreurs simples et détectera les erreurs doubles (arrêt du système Si une telle erreur est détectée).) Vous pouvez le voir de la façon dont les gens se plaignent régulièrement de ce qui semble être un problème de logiciel qui est résolu en lançant Memtest86 et en découvrant la mauvaise mémoire. Bien sûr, une défaillance transitoire causée par un rayon cosmique est différente d'une défaillance mémoire, mais il est pertinent à la question plus large de savoir dans quelle mesure vous devriez faire confiance à votre mémoire pour fonctionner correctement.

une analyse basée sur une taille de résident de 20 Mo pourrait être appropriée pour des applications triviales, mais les grands systèmes ont habituellement 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 essentiel à la vie (il tuera quelqu'un s'il échoue), il doit être écrit de manière à ce qu'il soit à l'abri de toute défaillance, ou qu'il se rétablisse automatiquement d'une telle défaillance. Tous les autres programmes, YMMV.

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

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

j'ai une fois programmé des appareils qui devaient voler dans l'espace, et puis vous (soi-disant, personne ne m'a jamais montré aucun papier à ce sujet, mais on a dit que c'était de notoriété publique dans le domaine) pourriez vous attendre à ce que les rayons cosmiques provoquent des erreurs tout le temps.

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

par exemple, notez que les pièces Intel destinées à des applications" embarquées " ont tendance à ajouter ECC à la fiche technique. Une piste de Bay Trail pour une tablette le manque, car il ferait la mémoire un peu plus cher et peut-être plus lent. 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 de toute façon beaucoup moins fiable que le HW. Mais pour les SKU destinés à être utilisés 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 provenant de perturbations aléatoires seraient un vrai problème.

certifiés selon la norme CEI 61508 et des normes similaires sont généralement soumis à des essais de démarrage qui vérifient que toute la mémoire vive est fonctionnelle (pas de bits collés à zéro ou un), ainsi qu'à des essais de gestion des erreurs à l'exécution qui tentent de: récupérez des erreurs détectées par ECC, et souvent aussi des tâches d'épurateur de mémoire qui passent et lisent et écrivent la mémoire en continu pour s'assurer que toutes les erreurs qui se produisent se font remarquer.

mais pour les logiciels PC grand public? Pas une grosse affaire. Pour un serveur de longue durée? Utilisez ECC et un gestionnaire de défauts. Si une erreur non rectifiable tue le noyau, qu'il en soit ainsi. Ou vous devenez paranoïaque et utilisez un système redondant avec une exécution lock-step pour que si un noyau est corrompu, l'autre puisse prenez le relais pendant que le premier noyau redémarre.

plus souvent, le bruit peut corrompre les données. Checksums sont utilisés pour lutter contre ce sur de nombreux niveaux; dans un câble de données, il ya généralement un bit de parité qui voyage à côté des données. Ce grandement réduit la probabilité de corruption. Ensuite, sur les niveaux d'analyse, les données absurdes sont typiquement ignorées, donc même si une certaine corruption a passé le bit de parité ou d'autres checksums, il serait dans la plupart des cas ignoré.

de plus, certains composants sont protégés électriquement pour bloquer le bruit (probablement pas les rayons cosmiques Je suppose).

mais en fin de compte, comme les autres répondants ont dit, Il ya le peu ou octet occasionnel qui est brouillé, et il est laissé au hasard si ce est un octet important ou non. Meilleur des cas, un rayon cosmique brouille l'un des vide bits et n'a absolument aucun effet, ou bloque l'ordinateur (ce qui est une bonne chose, parce que le l'ordinateur est gardé de faire du mal) ; mais dans le pire des cas, eh bien, je suis sûr que vous pouvez imaginer.

"rayons cosmiques événements" sont considérés comme ayant une distribution uniforme dans beaucoup de réponses ici, ce n'est pas toujours vrai (c'est à dire supernovae). Bien que" rayons cosmiques "par définition (au moins selon Wikipedia) vient de extérieur espace, je pense qu'il est juste d'inclure également local tempêtes solaires (alias éjection de masse coronale sous le même parapluie. Je crois que cela pourrait faire basculer plusieurs bits dans un court durée, assez potentiellement pour corrompre même la mémoire activée par ECC.

il est bien connu que les tempêtes solaires peuvent causer des ravages dans les systèmes électriques (comme la panne d'électricité au Québec en mars 1989 ). Il est fort probable que les systèmes informatiques puissent aussi être affectés.

il y a une dizaine d'années, j'étais assis juste à côté d'un autre type, nous étions assis avec chacun nos ordinateurs portables, c'était dans une période avec un temps solaire assez "orageux" (Assis dans l'Arctique, nous avons pu observer cela indirectement - beaucoup d'aurores boréales à voir). Soudain, au même moment , nos deux ordinateurs se sont écrasés. Il exécutait OS X, et moi Linux. Aucun de nous n'est habitué à ce que les ordinateurs portables s'écrasent - C'est assez rare sur Linux et OS X. Les bugs logiciels courants peuvent être plus ou moins écartés puisque nous tournions sur différents OS (et cela ne s'est pas produit pendant une seconde bissextile). J'ai rencontré à l'attribut "rayonnement cosmique".

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

j'en ai fait l'expérience - il n'est pas rare que les rayons cosmiques tournent 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 un essai de compression fastidieux et un essai de décompression pour tester l'intégrité, FC /B a montré un octet différent.

dans ce byte le MSB avait flippé. J'ai aussi flippé, craignant d'avoir un insecte fou qui ne ferait surface que dans des conditions très spécifiques - Je ne savais même pas où commencer à chercher.

mais quelque chose m'a dit de refaire le test. J'ai couru et il est passé. J'ai mis en place un script pour lancer le test 5 fois en une nuit. Au matin, tous les cinq étaient passés.

donc c'était définitivement un bit flip de rayon cosmique.

vous pourriez vouloir avoir un regard sur Matériel tolérant les défauts aussi bien.

par exemple, Stratus Technology construit des serveurs Wintel appelés ftServer qui avaient 2 ou 3" cartes principales " dans lock-step, en comparant le résultat des calculs. (cela se fait aussi parfois dans les véhicules spatiaux).

les serveurs Stratus ont évolué de chipset personnalisé à lockstep sur le plan arrière.

un système très similaire (mais logiciel) est le VMWare Tolérance d'erreur lockstep basé sur L'hyperviseur.

comme point de données, cela vient de se produire sur notre construction:

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

qui ressemble très fortement à un flip lors d'une compilation, dans un endroit très significatif d'un fichier source par hasard.

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