Estimación de la probabilidad de error de hardware


13

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?


Me imagino que los resultados de CPU / RAM son realmente estables en comparación con las consideraciones de disco y de la red.
meawoppl

Respuestas:


5

¿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(108)

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.


Eso suena exactamente como lo que necesito. ¿Tienes en mente ejemplos particulares?
Geoffrey Irving

1
Vería si hay algo entre los diversos informes de DoE que le interese. ¿Supongo que también sabes sobre exascale.org ? Debe haber mucho para leer allí para ti.
Wolfgang Bangerth

1
Geoff, el informe definitivo de exaescala es de Peter Kogge, y está disponible en línea . Eche un vistazo a cualquier aparición de la palabra resiliencia. Dicho esto, puedo señalarle a algunas personas en NERSC que podrían tener información más específica sobre esa máquina.
Aron Ahmadia

@AronAhmadia: Gracias, ese documento se ve muy bien. Estoy aceptando esta respuesta ya que debería cubrir más de las clases de errores que me interesan.
Geoffrey Irving

@Wolfgang: Esto me recuerda a mis días de guerra fría cuando los misiles Minuteman se programaban con puntos de control, de modo que si ocurría un destello de neutrones cerca, causando el apagado instantáneo del procesador, podría reiniciarse desde el punto de control más reciente. Si tomaba puntos de control en los momentos probables, se llamaba "reinicio protegido".
Mike Dunlavey

9

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


Gran estudio Confirma mucha intuición, viejo, caliente, de uso frecuente, el carnero casi completo es menos confiable. Estoy algo sorprendido de que no haya fallas particulares del proveedor o arquitecturas generalmente peores.
meawoppl

3

¿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.


¡Gracias! Obvio en retrospectiva, pero no se me había ocurrido.
Geoffrey Irving

2

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.


2
Desafortunadamente, es poco probable que su esquema para minar bitcoins sea aprobado. :)
Geoffrey Irving

Tee ji ji. Es solo una prueba de trabajo realmente. : P
meawoppl
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.