Estimation de la probabilité d'erreur matérielle

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?

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(10^8)$

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.

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

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.

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.