Estimación de la probabilidad de error de hardware

Digamos que ejecuto un cálculo de supercomputadora en 100k núcleos durante 4 horas en http://www.nersc.gov/users/computational-systems/edison/configuration , intercambiando alrededor de 4 PB de datos a través de la red y realizando aproximadamente 4 TB de I / O. El cálculo es todo entero, por lo que los resultados son correctos o incorrectos (sin errores numéricos intermedios).

Suponiendo que el código es correcto, me gustaría estimar la probabilidad de que el cálculo sea incorrecto debido a una falla de hardware. ¿Cuál es una buena manera de hacer esto? ¿Existen buenas fuentes para los números requeridos para hacer tal estimación?

¿Has mirado los diversos informes de exascale que han salido? Las fallas difíciles no son una preocupación importante hoy en día, claro, suceden, pero su frecuencia no es lo suficientemente alta como para causar una gran preocupación. Pero se estima que son lo suficientemente frecuentes en los sistemas de exascala con o más núcleos que los códigos deben estar preparados para reaccionar adecuadamente. Creo que estos problemas se han presentado en los informes sobre hojas de ruta hacia el exascale.$O(10^8)$

Recuerdo que entre los diversos modos de falla, los cambios de un solo bit en la memoria o en los núcleos del procesador no eran las preocupaciones más importantes. Por el contrario, fueron nodos enteros que cayeron, por ejemplo, debido a una falla del disco, fallas del sistema operativo, etc. Por lo tanto, los diseños actuales de exascale requieren la verificación periódica de los códigos en la memoria RAM flash, preferiblemente transmitiendo los datos del punto de control fuera del nodo. Los códigos deberán poder reiniciarse sobre la marcha desde un estado previamente guardado si el sistema encuentra que un nodo ha desaparecido, reemplazando este nodo con un nodo de arranque en caliente en otra parte del sistema.

Supongo que comienzas recolectando tasas de error de componentes, como DRAM, como esta investigación de Google sobre los errores de DRAM en la naturaleza: un estudio de campo a gran escala Encontraron ~ 1% de posibilidades de obtener un error no corregible por año.

No estoy seguro si eso es lo que te interesa. Estaría más interesado en errores indetectables. Errores tales que los métodos de comprobación de errores típicos no detectarían. Por ejemplo, cuando envía paquetes a través de la óptica, van acompañados de algún tipo de CRC, lo que permite una pequeña posibilidad de que se deslice un error.

ACTUALIZACIÓN: este documento Arquitecturas para la detección y recuperación de errores en línea en procesadores multinúcleo habla sobre una arquitectura multinúcleo confiable, pero también cubren diferentes aspectos de la confiabilidad del sistema y tiene bibliografía

¿Existen buenas fuentes para los números requeridos para hacer tal estimación?

Puede intentar preguntar a los administradores del clúster en el que está computando. Me imagino que, como parte de su proceso de validación, se han enfrentado al problema de estimar la probabilidad de errores de hardware.

Suena épico Si nadie ha hecho este experimento, puede considerar ejecutar 100k núcleos separados haciendo algo como volver a escribir una entrada sha1 una y otra vez, viendo cuál es la tasa de error. (Inconmensurable, sospecho), a partir de ahí haga lo mismo, pero pídales que intercambien los resultados de la cadena hash de vez en cuando para obtener sus tasas de error de red. Esto me imagino que también es muy pequeño, pero sospecho que puede obtener al menos un par usando su supercúmulo en unas pocas horas :)

Este enfoque asegura que cada cálculo sea correcto, ya que el hash es extremadamente sensible a los intercambios de un solo bit, mientras que incluso un cálculo de entero puede ocultar errores en las ramas, es decir, el cálculo completo no sería elíptico en cada estado de memoria consecutivo.

He estado trabajando en una forma de asegurarme de que el código haya sido ejecutado correctamente por un clúster externo cuya motivación es hacer trampa enviando resultados falsos. La solución con la que convergí es integrar el hash en el cálculo con cierta frecuencia que hace que la trampa sea menos eficiente que hacer el trabajo.