Estimation de la probabilité d'erreur matérielle


13

Supposons que j'exécute un calcul de superordinateur sur 100 000 cœurs pendant 4 heures sur http://www.nersc.gov/users/computational-systems/edison/configuration , échangeant environ 4 PB de données sur le réseau et effectuant environ 4 To d'I / O. Le calcul est entièrement entier, les résultats sont donc corrects ou incorrects (pas d'erreurs numériques intermédiaires).

En supposant que le code est correct, je voudrais estimer la probabilité que le calcul soit incorrect en raison d'une défaillance matérielle. Quelle est la bonne façon de procéder? Existe-t-il de bonnes sources pour les chiffres requis pour faire une telle estimation?


J'imagine que les résultats CPU / ram sont vraiment stables par rapport aux considérations de réseau et de disque.
meawoppl

Réponses:


5

Avez-vous examiné les différents rapports exascale qui ont été publiés? Les échecs difficiles ne sont pas une préoccupation majeure aujourd'hui - bien sûr, ils se produisent, mais leur fréquence n'est pas suffisamment élevée pour causer de graves inquiétudes. Mais ils sont estimés être suffisamment fréquents sur les systèmes ex-échelle avec ou plus de cœurs que les codes doivent être préparés pour réagir de manière appropriée. Je pense que ces questions ont été exposées dans les rapports sur les feuilles de route vers l'exascale.O(dix8)

Si je me souviens bien, parmi les différents modes de défaillance, les retournements de bits en mémoire ou sur les cœurs de processeur n'étaient pas les plus importants. Il s'agissait plutôt de nœuds entiers qui tombaient en panne, par exemple en raison d'une défaillance du disque, de défaillances du système d'exploitation, etc. Les codes devront alors pouvoir redémarrer à la volée à partir d'un état précédemment enregistré si le système rencontre qu'un nœud a disparu, en remplaçant ce nœud par un nœud de démarrage à chaud ailleurs dans le système.


Cela ressemble exactement à ce dont j'ai besoin. Avez-vous des exemples particuliers en tête?
Geoffrey Irving

1
Je verrais s'il y a quelque chose parmi les différents rapports du DoE qui vous intéresse. Je suppose que vous connaissez également exascale.org ? Il devrait y avoir beaucoup à lire pour vous.
Wolfgang Bangerth

1
Geoff, le rapport exascale définitif est de Peter Kogge et est disponible en ligne . Jetez un œil à toutes les occurrences du mot résilience. Cela dit, je peux vous indiquer quelques personnes au NERSC qui pourraient avoir des informations plus spécifiques sur cette machine.
Aron Ahmadia

@AronAhmadia: Merci, ce document a fière allure. J'accepte cette réponse car elle devrait couvrir davantage de classes d'erreurs qui m'intéressent.
Geoffrey Irving

@Wolfgang: Cela me rappelle mes jours de guerre froide où les missiles Minuteman étaient programmés avec des points de contrôle, de sorte que si un flash à neutrons se produisait à proximité, provoquant un arrêt instantané du processeur, il pourrait redémarrer à partir du point de contrôle le plus récent. S'il a pris des points de contrôle aux moments prouvés, il a été qualifié de "protégé contre le redémarrage".
Mike Dunlavey

9

Je suppose que vous commencez par collecter les taux d'erreur de composants, tels que la DRAM, comme cette recherche Google sur les erreurs DRAM dans la nature: une étude de terrain à grande échelle.Ils ont trouvé ~ 1% de chance d'obtenir une erreur non corrigible par an.

Je ne sais pas si c'est ce qui vous intéresse. Je serais plus intéressé par les erreurs indétectables. Erreurs telles que les méthodes typiques de vérification des erreurs ne seraient pas détectées. Par exemple, lorsque vous envoyez des paquets via l'optique, ils sont accompagnés d'une sorte de CRC, ce qui laisse une petite chance qu'une erreur se glisse.

MISE À JOUR: cet article Architectures for Online Error Detection and Recovery in Multicore Processors parle d'une architecture multicœur fiable, mais couvre également différents aspects de la fiabilité du système et possède une bibliographie


Grande étude. Cela confirme beaucoup d'intuition, vieux, chaud, fréquemment utilisé, le bélier presque plein est moins fiable. Je suis quelque peu surpris qu'il n'y ait pas de défaillances particulières des fournisseurs ou d'architectures généralement pires.
meawoppl

3

Existe-t-il de bonnes sources pour les chiffres requis pour faire une telle estimation?

Vous pourriez essayer de demander aux administrateurs du cluster sur lequel vous calculez. J'imagine que dans le cadre de leur processus de validation, ils ont été confrontés au problème d'estimation de la probabilité d'erreurs matérielles.


Merci! Évidemment avec le recul, mais cela ne m'est pas venu à l'esprit.
Geoffrey Irving

2

Cela semble épique. Si personne n'a fait cette expérience, vous pourriez envisager d'exécuter 100 000 cœurs séparés en faisant quelque chose comme ressasser une entrée sha1 encore et encore, voir quel est le taux d'erreur. (Non mesurable, je suppose), à ​​partir de là, faites de même, mais demandez-leur d'échanger les résultats de la chaîne de hachage de temps en temps pour obtenir les taux d'erreur de votre réseau. J'imagine que c'est aussi très petit, mais je pense que vous pouvez obtenir au moins un couple en utilisant votre superamas en quelques heures :)

Cette approche garantit que chaque calcul est correct, car le hachage est extrêmement sensible aux échanges sur un seul bit, alors que même un calcul entier uniquement peut masquer des erreurs dans les branches, c'est-à-dire que le calcul entier ne serait pas elliptique sur chaque état de mémoire consécutif.

J'ai travaillé sur un moyen de s'assurer que le code a été correctement exécuté par un cluster externe qui a pour motivation de tricher en soumettant de faux résultats. La solution sur laquelle j'ai convergé est d'intégrer le hachage dans le calcul avec une certaine fréquence qui rend la tricherie moins efficace que de faire le travail.


2
Malheureusement, il est peu probable que votre schéma d'extraction de bitcoins soit approuvé. :)
Geoffrey Irving

Tee hee hee. C'est juste une preuve de travail vraiment. : P
meawoppl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.