Note : Cette réponse ne concerne pas la physique, mais les erreurs de mémoire silencieuses avec les modules de mémoire non-ECC. Certaines de ces erreurs peuvent provenir de l'espace extérieur, d'autres de l'espace intérieur de l'ordinateur.
Il existe plusieurs études sur les défaillances de la mémoire ECC dans les grandes fermes de serveurs comme les clusters du CERN et les centres de données de Google. Le matériel de classe serveur doté de l'ECC peut détecter et corriger toutes les erreurs à un seul bit et détecter de nombreuses erreurs à plusieurs bits.
Nous pouvons supposer qu'il y a beaucoup d'ordinateurs de bureau non CEC (et de smartphones mobiles non CEC). Si nous vérifions les articles sur les taux d'erreurs corrigibles par ECC (bitflips simples), nous pouvons connaître le taux de corruptions silencieuses de la mémoire non ECC.
Donc, si le programme a un grand ensemble de données (plusieurs Go), ou a un taux élevé de lecture ou d'écriture de la mémoire (Go/s ou plus), et qu'il fonctionne 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 longues séries de clusters sur des milliers de PC non ECC, comme le calcul en grille à l'échelle de l'internet de BOINC, comporteront toujours des erreurs dues à des erreurs binaires de mémoire ainsi qu'à 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 d'un seul bit, comme nous le voyons dans le rapport 2012 de Sandia, il peut y avoir des flips de deux bits chaque jour, de sorte que vous n'aurez aucune chance d'exécuter un programme parallèle de taille complète pendant plusieurs jours (sans point de contrôle régulier et en redémarrant à partir du dernier bon point de contrôle en cas de double erreur). Les énormes machines auront également des bit-flips dans leurs caches et registres cpu (à la fois architecturaux et déclencheurs 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 a rendu l'âme plusieurs semaines plus tard. Il 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 dans le système de fichiers racine.
