statistics physics probability error-detection risk-analysis

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



physics probability (15)

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

"Ya que 2 -128 es 1 de cada 340282366920938463463374607431768211456, creo que estamos justificados en arriesgarnos aquí, incluso si estos cálculos no son suficientes en unos pocos miles de millones ... Estamos en mayor 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?

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

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

Puedes leer la patente completa aquí .

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 - ^

Se ve muy fuertemente como un pequeño cambio de posición durante una compilación, en un lugar muy significativo en un archivo fuente por casualidad.

No estoy necesariamente diciendo que esto fue un "rayo cósmico", pero los síntomas coinciden.

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

Sun declara: (Parte No. 816-5053-10 de abril de 2002)

En general, los errores blandos de los rayos cósmicos se producen en la memoria DRAM a una velocidad de ~ 10 a 100 FIT / MB (1 FIT = 1 dispositivo falla en 1 billón de horas). Por lo tanto, un sistema con 10 GB de memoria debería mostrar un evento ECC cada 1,000 a 10,000 horas, y un sistema con 100 GB mostraría 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.

De Wikipedia :

Los estudios realizados por IBM en la década de 1990 sugieren que las computadoras suelen experimentar 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 del fallo. Además, debido al tamaño más compacto de los chips, como lo comentó Joe, la tasa de fracaso podría ser diferente a la de hace 20 años.

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

Por ejemplo, Stratus Technology construye servidores Wintel llamados ftServer que tenían 2 o 3 "mainboards" en el 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 conjunto de chips personalizado a un bloqueo en el plano posterior.

Un sistema muy similar (pero software) es el bloqueo de tolerancia a fallas de VMWare basado en el hipervisor.

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. A Bay Trail para una tableta le falta, ya que haría que la memoria fuera un poco más cara y posiblemente más lenta. Y si una tableta bloquea un programa de vez en cuando en una luna azul, al usuario no le importa mucho. El software en sí es mucho menos confiable que el HW de todos modos. Sin embargo, para los SKU destinados al uso en maquinaria industrial y automotriz, ECC es obligatorio. Ya que aquí, esperamos que el SW sea mucho más confiable, y los errores de las sorpresas aleatorias serían un problema real.

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

¿Pero para el software de PC convencional? No es un gran trato. ¿Para un servidor de larga duración? Use ECC y un manejador de fallas. Si un error no corregible mata el núcleo, que así sea. O se vuelve paranoico y usa un sistema redundante con la ejecución de pasos de bloqueo, de modo que si un núcleo se corrompe, el otro puede asumir el control mientras el primer núcleo se reinicia.

He experimentado esto: no es raro que los rayos cósmicos se muevan 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 unos 500 MB o más descomprimidos.

Después de una ejecución de compresión tediosa 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 volteado. También me volteé, preocupándome de tener un error loco que solo surgiría en condiciones muy específicas, ni siquiera sabía 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 todos los 5 habían pasado.

Así que eso fue definitivamente un giro de bits de rayos cósmicos.

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

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

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

El enlace de Corsair en la página desafortunadamente parece estar muerto.

Más a menudo, el ruido puede corromper los datos. Checksums se utilizan para combatir esto en muchos niveles; en un cable de datos normalmente 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 normalmente se ignoran, por lo que incluso si alguna corrupción supera el bit de paridad u otras sumas de comprobación, en la mayoría de los casos se ignoraría.

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

Pero al final, como han dicho los demás respondedores, existe un bit o byte ocasional que se codifica, y queda al azar si se trata de un byte significativo o no. En el mejor de los casos, un rayo cósmico mezcla 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 en el peor de los casos, bueno, estoy seguro que puedes imaginarlo.

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

Hay varios estudios de fallas de memoria de ECC en granjas de servidores grandes 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 múltiples bits.

Podemos asumir que hay muchos escritorios que no son ECC (y teléfonos inteligentes móviles que no son ECC). Si revisamos los documentos en busca de tasas de error corregibles por ECC (bitflips individuales), podemos conocer la tasa de corrupción de memoria silenciosa en la memoria sin ECC.

Por lo tanto, si el programa tiene un conjunto de datos grande (varios GB), o tiene una alta velocidad de lectura o escritura (GB / s o más), y se ejecuta durante varias horas, podemos esperar hasta varios cambios de bit silenciosos en el hardware del escritorio. Esta tasa no es detectable por memtest, y los módulos DRAM son buenos.

El clúster largo se ejecuta en miles de PC que no son de ECC, como la computación grid de Internet de BOINC siempre tendrá errores de bit-flips 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 de errores de un solo bit, como vemos en el informe de 2012 de Sandia, puede haber flips de doble bit todos los días, por lo que no tendrá la oportunidad de ejecutarse en paralelo de tamaño completo. programa durante varios días (sin control regular y reinicio desde el último punto de control bueno en caso de doble error). Las enormes máquinas también obtendrán bit-flips en sus cachés y registros de CPU (tanto los disparadores de chips internos y arquitectónicos, 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 una 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 quiere reiniciar después de corregir los errores. Pero en cada reinicio siguiente (hice alrededor de 5-6 de ellos) todavía hay errores encontrados en el sistema de archivos raíz.

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 de acuerdo con Wikipedia) provienen del espacio exterior , creo que es justo incluir también tormentas solares locales (también conocida como eyección de masa coronal bajo el mismo paraguas. Creo que podría causar que varios bits se muevan dentro de una corto período de tiempo, potencialmente suficiente para dañar incluso la memoria habilitada para ECC.

Es bien sabido que las tormentas solares pueden causar algunos estragos en los sistemas eléctricos (como el corte de energía de Quebec en marzo de 1989 ). Es bastante probable que los sistemas informáticos también puedan verse afectados.

Hace unos 10 años, estaba sentado al lado de otro chico, estábamos sentados con cada uno de nuestros equipos portátiles, estaba en un período con un clima solar bastante "tormentoso" (sentados en el Ártico, podíamos observar esto indirectamente, muchas auroras boreales para ser visto). De repente, en el mismo instante, ambas computadoras portátiles se estrellaron. Él estaba ejecutando OS X, y yo estaba ejecutando Linux. Ninguno de nosotros está acostumbrado a que las computadoras portátiles se caigan, es algo muy raro en Linux y OS X. Los errores comunes de software se pueden descartar más o menos ya que estábamos ejecutando en diferentes sistemas operativos (y no sucedió durante un salto segundo). He venido 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, atribuimos en broma la falla a la "radiación cósmica". :-)

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 buen ejemplo. Di lo que quieras sobre un cable del acelerador, pero no es un software.

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

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

Wikipedia cita un [15] en los años 90 que sugiere que "las computadoras suelen experimentar alrededor de 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 proporcionó referencias adicionales. Personalmente, encuentro que ese número es muy alto, pero tal vez la mayoría de los errores de memoria inducidos por los rayos cósmicos no causen ningún problema real o notable.

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