Rayos cósmicos: ¿cuál es la probabilidad de que afecten a un programa?

Una vez más, estaba en una revisión de diseño, y encontré la afirmación de que la probabilidad de un escenario particular era "menor que el riesgo de que los rayos cósmicos" afectaran el programa, y ​​se me ocurrió que no tenía la menor idea de qué era eso. la probabilidad es

"Dado que 2 ^-128 es 1 de 340282366920938463463374607431768211456, creo que estamos justificados para arriesgarnos aquí, incluso si estos cálculos están desactivados por un factor de unos pocos miles de millones ... Estamos mucho más en riesgo de que los rayos cósmicos jodernos, creo ".

¿Es correcto este programador? ¿Cuál es la probabilidad de que un rayo cósmico golpee una computadora y afecte la ejecución del programa?

De Wikipedia :

Los estudios de IBM en la década de 1990 sugieren que las computadoras generalmente experimentan aproximadamente un error inducido por rayos cósmicos por 256 megabytes de RAM por mes. ^[15]

Esto significa una probabilidad de 3.7 × 10 ^-9 por byte por mes, o 1.4 × ^10-15 por byte por segundo. Si su programa se ejecuta durante 1 minuto y ocupa 20 MB de RAM, entonces la probabilidad de falla sería

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

La comprobación de errores puede ayudar a reducir las consecuencias de la falla. Además, debido al tamaño más compacto de los chips como comentó Joe, la tasa de falla podría ser diferente de lo que era hace 20 años.

Al parecer, no es insignificante. De este artículo de New Scientist , una cita de una solicitud de patente de Intel:

"Se han producido bloqueos informáticos inducidos por rayos cósmicos y se espera que aumenten con la frecuencia a medida que los dispositivos (por ejemplo, transistores) disminuyan de tamaño en los chips. Se prevé que este problema se convierta en un importante limitador de la confiabilidad de la computadora en la próxima década".

Puedes leer la patente completa aquí .

Nota: esta respuesta no se trata de física, sino de errores de memoria silenciosa con módulos de memoria no ECC. Algunos de los errores pueden provenir del espacio exterior y otros, del espacio interior del escritorio.

Hay varios estudios de fallas de memoria ECC en grandes granjas de servidores como clústeres CERN y centros de datos de Google. El hardware de clase de servidor con ECC puede detectar y corregir todos los errores de un solo bit, y detectar muchos errores de varios bits.

Podemos suponer que hay muchas computadoras de escritorio que no son ECC (y teléfonos inteligentes móviles que no son ECC). Si verificamos en los documentos las tasas de error corregibles por ECC (bits de bits únicos), podemos conocer la tasa de corrupción de memoria silenciosa en la memoria no ECC.

• Estudio a gran escala del CERN 2007 "Integridad de los datos" : los proveedores declaran " Tasa de error de bits de ^10-12 para sus módulos de memoria ", " una tasa de error observada es 4 órdenes de magnitud menor de lo esperado ". Para las tareas de uso intensivo de datos (8 GB / s de lectura de memoria), esto significa que puede producirse un cambio de un solo bit cada minuto ( ^10-12 vendedores BER) o una vez cada dos días ( ^10-16 BER).

• El artículo de 2009 "Errores de DRAM en la naturaleza: un estudio de campo a gran escala" de Google dice que puede haber hasta 25000-75000 FIT de un bit por Mbit ( fallas en el tiempo por billón de horas ), que es igual a 1 - 5 bit errores por hora para 8GB de RAM después de mis cálculos. El artículo dice lo mismo: " tasas de error promedio corregibles de 2000–6000 por GB por año ".

• Informe Sandia 2012 "Detección y corrección de la corrupción silenciosa de datos para computación de alto rendimiento a gran escala" : "los cambios de doble bit se consideraron improbables", pero en el denso Cray XT5 de ORNL son "a razón de uno por día para más de 75,000 DIMM" incluso con ECC. Y los errores de un solo bit deberían ser mayores.

Entonces, si el programa tiene un gran conjunto de datos (varios GB), o tiene una alta velocidad de lectura o escritura de memoria (GB / so más), y se ejecuta durante varias horas, entonces podemos esperar hasta varios cambios de bits silenciosos en el hardware del escritorio. Memtest no puede detectar esta tasa, y los módulos DRAM son buenos.

El clúster largo se ejecuta en miles de PC que no son ECC, como la computación de cuadrícula de Internet BOINC siempre tendrá errores de cambios de bits de memoria y también de errores silenciosos de disco y red.

Y para máquinas más grandes (10 miles de servidores) incluso con protección ECC contra errores de un solo bit, como vemos en el informe de Sandia 2012, puede haber cambios de doble bit todos los días, por lo que no tendrá la oportunidad de ejecutar paralelos de tamaño completo programa durante varios días (sin puntos de control regulares y reinicio desde el último punto de control correcto en caso de doble error). Las máquinas enormes también recibirán cambios de bits en sus cachés y registros de CPU (disparadores de chips tanto arquitectónicos como internos, por ejemplo, en la ruta de datos ALU), porque no todos están protegidos por ECC.

PD: Las cosas serán mucho peores si el módulo DRAM es malo. Por ejemplo, instalé una nueva DRAM en la computadora portátil, que murió varias semanas después. Comenzó a dar muchos errores de memoria. Lo que obtengo: la computadora portátil se cuelga, Linux se reinicia, ejecuta fsck, encuentra errores en el sistema de archivos raíz y dice que desea reiniciar después de corregir los errores. Pero en cada próximo reinicio (hice alrededor de 5-6 de ellos) todavía se encuentran errores en el sistema de archivos raíz.

Wikipedia cita un estudio de IBM en los años 90 que sugiere que "las computadoras suelen experimentar un error inducido por rayos cósmicos por 256 megabytes de RAM por mes". Desafortunadamente, la cita fue a un artículo en Scientific American, que no dio más referencias. Personalmente, encuentro que ese número es muy alto, pero quizás la mayoría de los errores de memoria inducidos por los rayos cósmicos no causan ningún problema real o notable.

Por otro lado, las personas que hablan de probabilidades cuando se trata de escenarios de software generalmente no tienen idea de lo que están hablando.

Bueno, los rayos cósmicos aparentemente causaron el mal funcionamiento de la electrónica en los automóviles Toyota, por lo que diría que la probabilidad es muy alta :)

¿Los rayos cósmicos realmente están causando problemas con Toyota?

Con ECC puede corregir los errores de 1 bit de los rayos cósmicos. Para evitar el 10% de los casos en los que los rayos cósmicos provocan errores de 2 bits, las celdas de ECC generalmente se entrelazan sobre chips, por lo que no hay dos celdas una al lado de la otra. Por lo tanto, un evento de rayos cósmicos que afecta a dos células dará como resultado dos errores corregibles de 1 bit.

Estados del Sol: (Parte No. 816-5053-10 de abril de 2002)

En términos generales, los errores suaves de rayos cósmicos ocurren en la memoria DRAM a una velocidad de ~ 10 a 100 FIT / MB (1 FIT = 1 dispositivo falla en mil millones de horas). Por lo tanto, un sistema con 10 GB de memoria debe mostrar un evento ECC cada 1,000 a 10,000 horas, y un sistema con 100 GB mostrará un evento cada 100 a 1,000 horas. Sin embargo, esta es una estimación aproximada que cambiará en función de los efectos descritos anteriormente.

Los errores de memoria son reales, y la memoria ECC ayuda. La memoria ECC implementada correctamente corregirá errores de un solo bit y detectará errores de doble bit (detendrá el sistema si se detecta dicho error). Puede ver esto en la frecuencia con la que la gente se queja de lo que parece ser un problema de software que se resuelve ejecutando Memtest86 y descubriendo mala memoria. Por supuesto, una falla transitoria causada por un rayo cósmico es diferente a una pieza de memoria que falla constantemente, pero es relevante para la pregunta más amplia de cuánto debe confiar en que su memoria funcione correctamente.

Un análisis basado en un tamaño residente de 20 MB puede ser apropiado para aplicaciones triviales, pero los sistemas grandes tienen rutinariamente múltiples servidores con grandes memorias principales.

Enlace interesante: http://cr.yp.to/hardware/ecc.html

Desafortunadamente, el enlace de Corsair en la página parece estar muerto.

Este es un problema real, y es por eso que la memoria ECC se usa en servidores y sistemas integrados. Y por qué los sistemas de vuelo son diferentes de los basados ​​en tierra.

Por ejemplo, tenga en cuenta que las piezas de Intel destinadas a aplicaciones "integradas" tienden a agregar ECC a la hoja de especificaciones. Carece de un Bay Trail para una tableta, ya que haría la memoria un poco más cara y posiblemente más lenta. Y si una tableta bloquea un programa cada vez en una luna azul, al usuario no le importa mucho. El software en sí mismo es mucho menos confiable que el HW de todos modos. Pero para los SKU destinados a uso en maquinaria industrial y automotriz, el ECC es obligatorio. Desde aquí, esperamos que el SW sea mucho más confiable, y los errores de alteraciones aleatorias serían un problema real.

Los sistemas certificados según IEC 61508 y estándares similares generalmente tienen pruebas de arranque que verifican que toda la RAM sea funcional (sin bits atascados en cero o uno), así como manejo de errores en tiempo de ejecución que intenta recuperarse de errores detectados por ECC, y a menudo también las tareas de depuración de memoria que pasan y leen y escriben memoria continuamente para asegurarse de que se noten los errores que ocurran.

¿Pero para el software de PC convencional? No es un gran trato. ¿Para un servidor de larga vida? Use ECC y un manejador de fallas. Si un error no corregible mata el núcleo, que así sea. O te vuelves paranoico y usas un sistema redundante con ejecución de paso de bloqueo para que si un núcleo se corrompe, el otro pueda hacerse cargo mientras el primer núcleo se reinicia.

Si un programa es crítico para la vida (matará a alguien si falla), debe escribirse de tal manera que sea a prueba de fallas o se recupere automáticamente de tal falla. Todos los demás programas, YMMV.

Los toyotas son un ejemplo de ello. Di lo que quieras sobre un cable del acelerador, pero no es un software.

Ver también http://en.wikipedia.org/wiki/Therac-25

Una vez programé dispositivos que iban a volar en el espacio, y luego (supuestamente, nadie me mostró ningún documento al respecto, pero se decía que era de conocimiento común en el negocio) podría esperar que los rayos cósmicos induzcan errores todo el tiempo.

Se considera que los "eventos de rayos cósmicos" tienen una distribución uniforme en muchas de las respuestas aquí, esto puede no ser siempre cierto (es decir, supernovas). Aunque los "rayos cósmicos", por definición (al menos según Wikipedia) provienen del espacio exterior , creo que es justo incluir también tormentas solares locales (también conocido como eyección de masa coronal bajo el mismo paraguas. Creo que podría causar que varios bits se vuelvan dentro de un breve intervalo de tiempo, potencialmente suficiente para corromper incluso la memoria habilitada para ECC.

Es bien sabido que las tormentas solares pueden causar bastantes estragos en los sistemas eléctricos (como el apagón de Quebec en marzo de 1989 ). Es muy probable que los sistemas informáticos también puedan verse afectados.

Hace unos 10 años estaba sentado justo al lado de otro chico, estábamos sentados con cada una de nuestras computadoras portátiles, fue en un período con un clima solar bastante "tormentoso" (sentados en el Ártico, pudimos observar esto indirectamente: muchas auroras boreales para ser visto). De repente, en el mismo instante, nuestras dos computadoras portátiles se estrellaron. Estaba ejecutando OS X y yo estaba ejecutando Linux. Ninguno de los dos estamos acostumbrados a que las computadoras portátiles se estrellen; es algo bastante raro en Linux y OS X. Los errores de software comunes se pueden descartar más o menos ya que estábamos ejecutando en diferentes sistemas operativos (y no sucedió durante un salto) segundo). He llegado a atribuir ese evento a la "radiación cósmica".

Más tarde, la "radiación cósmica" se ha convertido en una broma interna en mi lugar de trabajo. Cada vez que sucede algo con nuestros servidores y no podemos encontrar ninguna explicación para ello, en broma atribuimos la falla a la "radiación cósmica". :-)

Más a menudo, el ruido puede dañar los datos. Las sumas de control se usan para combatir esto en muchos niveles; En un cable de datos, generalmente hay un bit de paridad que viaja junto con los datos. Esto reduce en gran medida la probabilidad de corrupción. Luego, en los niveles de análisis, los datos sin sentido generalmente se ignoran, por lo que incluso si alguna corrupción superara el bit de paridad u otras sumas de verificación, en la mayoría de los casos se ignoraría.

Además, algunos componentes están protegidos eléctricamente para bloquear el ruido (probablemente no los rayos cósmicos, supongo).

Pero al final, como han dicho los otros respondedores, hay un bit o byte ocasional que se codifica, y se deja al azar si es un byte significativo o no. En el mejor de los casos, un rayo cósmico revuelve uno de los bits vacíos y no tiene absolutamente ningún efecto, o bloquea la computadora (esto es algo bueno, porque se evita que la computadora haga daño); pero el peor de los casos, bueno, estoy seguro de que te lo puedes imaginar.

He experimentado esto: no es raro que los rayos cósmicos cambien un poco, pero es muy poco probable que una persona observe esto.

Estaba trabajando en una herramienta de compresión para un instalador en 2004. Mis datos de prueba fueron algunos archivos de instalación de Adobe de aproximadamente 500 MB o más descomprimidos.

Después de una tediosa ejecución de compresión y una ejecución de descompresión para probar la integridad, FC / B mostró un byte diferente.

Dentro de ese byte, el MSB había cambiado. También me volteé, preocupándome de tener un error loco que solo aparecería en condiciones muy específicas, ni siquiera sabía por dónde empezar a buscar.

Pero algo me dijo que volviera a hacer la prueba. Lo corrí y pasó. Configuré un script para ejecutar la prueba 5 veces durante la noche. En la mañana habían pasado los 5.

Así que definitivamente fue un cambio de bit de rayos cósmicos.

Es posible que desee echar un vistazo también al hardware Fault Tolerant.

Por ejemplo, Stratus Technology construye servidores Wintel llamados ftServer que tenían 2 o 3 "placas base" en paso de bloqueo, comparando el resultado de los cálculos. (esto también se hace en vehículos espaciales a veces).

Los servidores Stratus evolucionaron de un chipset personalizado a un bloqueo en el plano posterior.

Un sistema muy similar (pero de software) es el bloqueo VMWare Fault Tolerance basado en el hipervisor.

Como punto de datos, esto acaba de suceder en nuestra compilación:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

Eso se parece mucho a un pequeño cambio durante una compilación, en un lugar muy significativo en un archivo fuente por casualidad.

No estoy diciendo necesariamente que se trataba de un "rayo cósmico", pero el síntoma coincide.