Raios Cósmicos: qual é a probabilidade de eles afetarem um programa?

Mais uma vez, eu estava em uma revisão de projeto e encontrei a alegação de que a probabilidade de um cenário específico era "menor que o risco de raios cósmicos" afetando o programa, e me ocorreu que eu não tinha a menor idéia do que isso probabilidade é.

"Como 2 ^-128 é 1 em 340282366920938463463374607431768211456, acho que temos justificativa em arriscar aqui, mesmo que esses cálculos não funcionem por um fator de alguns bilhões ... Estamos muito em risco de os raios cósmicos estrague-nos, eu acredito. "

Este programador está correto? Qual é a probabilidade de um raio cósmico atingir um computador e afetar a execução do programa?

Da Wikipedia :

Estudos realizados pela IBM nos anos 90 sugerem que os computadores geralmente experimentam cerca de um erro induzido por raios cósmicos por 256 megabytes de RAM por mês. ^[15]

Isso significa uma probabilidade de 3,7 × 10 ^-9 por byte por mês ou 1,4 × 10 ^-15 por byte por segundo. Se o seu programa for executado por 1 minuto e ocupar 20 MB de RAM, a probabilidade de falha será

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

A verificação de erros pode ajudar a reduzir as consequências da falha. Além disso, devido ao tamanho mais compacto dos chips, como comentado por Joe, a taxa de falhas pode ser diferente da que era há 20 anos.

Aparentemente, não é insignificante. A partir deste artigo do New Scientist , uma citação de um pedido de patente Intel:

"Falhas de computador induzidas por raios cósmicos ocorreram e devem aumentar com a frequência, à medida que os dispositivos (por exemplo, transistores) diminuem de tamanho em chips. Esse problema é projetado para se tornar um grande limitador da confiabilidade do computador na próxima década."

Você pode ler a patente completa aqui .

Nota: esta resposta não é sobre física, mas sobre erros de memória silenciosa com módulos de memória não-ECC. Alguns erros podem vir do espaço sideral e outros - do espaço interno da área de trabalho.

Existem vários estudos sobre falhas de memória ECC em grandes farms de servidores, como clusters CERN e datacenters do Google. O hardware da classe de servidor com ECC pode detectar e corrigir todos os erros de um único bit e detectar muitos erros de vários bits.

Podemos supor que haja muitos desktops não ECC (e smartphones móveis não ECC). Se verificarmos os papéis quanto a taxas de erro corrigíveis por ECC (simples bitflips), podemos saber a taxa de corrupção de memória silenciosa na memória não-ECC.

• Estudo de grande escala do CERN 2007 "Integridade de dados" : os fornecedores declaram " Taxa de erros de 10 a ¹² para seus módulos de memória ", " uma taxa de erro observada é 4 ordens de magnitude abaixo do esperado ". Para tarefas com uso intenso de dados (leitura de 8 GB / s de memória), isso significa que um único bit flip pode ocorrer a cada minuto ( ^10-12 fornecedores BER) ou uma vez a cada dois dias ( ^10-16 BER).

• Artigo do Google em 2009 "Erros DRAM em estado selvagem: um estudo de campo em larga escala" diz que pode haver até 25000-75000 FIT de um bit por Mbit ( falhas no tempo por bilhão de horas ), que é igual a 1 - 5 bits erros por hora para 8 GB de RAM após meus cálculos. O artigo diz o mesmo: " taxas médias de erros corrigíveis de 2000 a 6000 por GB por ano ".

• Relatório Sandia 2012 "Detecção e correção de corrupção de dados silenciosos para computação de alto desempenho em larga escala" : "inversões de bit duplo foram consideradas improváveis", mas no denso Cray XT5 da ORNL elas são "a uma taxa por dia por mais de 75.000 DIMMs" com ECC. E erros de bit único devem ser maiores.

Portanto, se o programa tiver um grande conjunto de dados (vários GB) ou uma alta taxa de leitura ou gravação na memória (GB / s ou mais), e ele for executado por várias horas, podemos esperar até vários movimentos de bits silenciosos no hardware da área de trabalho. Essa taxa não é detectável pelo memtest e os módulos DRAM são bons.

Clusters longos são executados em milhares de PCs não-ECC, como o BOINC, a computação em grade na Internet sempre terá erros nos bits de memória e também nos erros silenciosos de disco e de rede.

E para máquinas maiores (10 milhares de servidores), mesmo com proteção ECC contra erros de bit único, como podemos ver no relatório de Sandia de 2012, pode haver inversões de bit duplo todos os dias, para que você não tenha chance de executar paralelo em tamanho real programa por vários dias (sem ponto de verificação regular e reinicialização do último ponto de verificação bom em caso de erro duplo). As grandes máquinas também receberão inversões de bits em seus caches e registros de CPU (ambos os gatilhos arquitetônicos e internos, como no caminho de dados da ALU), porque nem todos são protegidos pelo ECC.

PS: As coisas ficarão muito piores se o módulo DRAM estiver ruim. Por exemplo, instalei uma nova DRAM no laptop, que morreu várias semanas depois. Começou a dar muitos erros de memória. O que recebo: o laptop trava, o linux é reinicializado, executa o fsck, encontra erros no sistema de arquivos raiz e diz que deseja reinicializar após corrigir os erros. Mas a cada reinicialização seguinte (fiz cerca de 5-6), ainda existem erros encontrados no sistema de arquivos raiz.

A Wikipedia cita um estudo da IBM nos anos 90, sugerindo que "os computadores geralmente experimentam cerca de um erro induzido por raios cósmicos por 256 megabytes de RAM por mês". Infelizmente, a citação foi para um artigo da Scientific American, que não forneceu outras referências. Pessoalmente, acho esse número muito alto, mas talvez a maioria dos erros de memória induzidos por raios cósmicos não causem problemas reais ou perceptíveis.

Por outro lado, as pessoas que falam sobre probabilidades quando se trata de cenários de software geralmente não têm idéia do que estão falando.

Bem, os raios cósmicos aparentemente causaram o mau funcionamento dos carros da Toyota, então eu diria que a probabilidade é muito alta :)

Os raios cósmicos estão realmente causando problemas à Toyota?

Com o ECC, você pode corrigir os erros de 1 bit dos Cosmic Rays. Para evitar 10% dos casos em que os raios cósmicos resultam em erros de 2 bits, as células ECC são normalmente intercaladas sobre chips, de modo que não há duas células próximas umas das outras. Um evento de raio cósmico que afeta duas células resultará em dois erros corrigíveis de 1bit.

A Sun declara: (número de peça 816-5053-10 de abril de 2002)

De um modo geral, erros leves de raios cósmicos ocorrem na memória DRAM a uma taxa de ~ 10 a 100 FIT / MB (falha de 1 FIT = 1 dispositivo em 1 bilhão de horas). Portanto, um sistema com 10 GB de memória deve mostrar um evento ECC a cada 1.000 a 10.000 horas, e um sistema com 100 GB mostrará um evento a cada 100 a 1.000 horas. No entanto, essa é uma estimativa aproximada que mudará em função dos efeitos descritos acima.

Os erros de memória são reais e a memória ECC ajuda. A memória ECC corretamente implementada corrigirá erros de bit único e detectará erros de bit duplo (interromperá o sistema se esse erro for detectado.) Você pode ver isso com a frequência com que as pessoas reclamam do que parece ser um problema de software resolvido executando o Memtest86 e descobrindo memória ruim. É claro que uma falha transitória causada por um raio cósmico é diferente de um pedaço de memória com falha consistente, mas é relevante para a questão mais ampla de quanto você deve confiar em sua memória para funcionar corretamente.

Uma análise baseada em um tamanho residente de 20 MB pode ser apropriada para aplicativos triviais, mas grandes sistemas rotineiramente têm vários servidores com grandes memórias principais.

Link interessante: http://cr.yp.to/hardware/ecc.html

Infelizmente, o link da Corsair na página parece estar morto.

Esse é um problema real e é por isso que a memória ECC é usada em servidores e sistemas incorporados. E por que os sistemas voadores são diferentes dos sistemas terrestres.

Por exemplo, observe que as peças da Intel destinadas a aplicativos "incorporados" tendem a adicionar ECC à folha de especificações. Um Trail Bay para um tablet não possui, pois tornaria a memória um pouco mais cara e possivelmente mais lenta. E se um tablet trava um programa de vez em quando na lua azul, o usuário não se importa muito. O software em si é muito menos confiável que o HW de qualquer maneira. Porém, para os SKUs destinados ao uso em máquinas industriais e automotivas, o ECC é obrigatório. Desde aqui, esperamos que o SW seja muito mais confiável, e os erros de problemas aleatórios seriam um problema real.

Os sistemas certificados pela IEC 61508 e padrões semelhantes geralmente têm ambos os testes de inicialização que verificam se toda a RAM está funcional (sem bits presos em zero ou um), bem como a manipulação de erros em tempo de execução que tenta se recuperar dos erros detectados pelo ECC, e geralmente também tarefas de depuração de memória que passam e leem e gravam memória continuamente para garantir que quaisquer erros que ocorram sejam notados.

Mas para o software de PC convencional? Não é grande coisa. Para um servidor de longa duração? Use ECC e um manipulador de falhas. Se um erro incorrigível matar o kernel, que assim seja. Ou você fica paranóico e usa um sistema redundante com execução de bloqueio para que, se um núcleo for corrompido, o outro possa assumir o controle enquanto o primeiro núcleo é reinicializado.

Se um programa é essencial para a vida (ele mata alguém se falhar), ele precisa ser escrito de tal forma que seja à prova de falhas ou se recupere automaticamente de tal falha. Todos os outros programas, YMMV.

Toyotas são um exemplo disso. Diga o que quiser sobre um cabo do acelerador, mas não é um software.

Veja também http://en.wikipedia.org/wiki/Therac-25

Uma vez eu programei dispositivos que voariam no espaço, e então você (supostamente, ninguém nunca me mostrou nenhum artigo sobre isso, mas foi dito que era de conhecimento comum nos negócios) poderia esperar que os raios cósmicos induzissem erros o tempo todo.

"eventos de raios cósmicos" são considerados como tendo uma distribuição uniforme em muitas das respostas aqui, isso nem sempre pode ser verdade (isto é, supernovas). Embora os "raios cósmicos", por definição (pelo menos de acordo com a Wikipedia), venham do espaço sideral , acho justo incluir também tempestades solares locais (também conhecidas como ejeção de massa coronal sob o mesmo guarda-chuva). tempo curto, potencialmente suficiente para corromper até a memória habilitada para ECC.

É sabido que tempestades solares podem causar grandes estragos nos sistemas elétricos (como a falta de energia em Quebec, em março de 1989 ). É bem provável que os sistemas de computador também possam ser afetados.

Cerca de 10 anos atrás, eu estava sentado ao lado de outro cara, estávamos sentados um com o outro em nossos laptops, estava em um período com um clima solar bastante "tempestuoso" (sentado no ártico, podíamos observar isso indiretamente - muita aurora boreal para ser visto). De repente - no mesmo instante - nossos laptops falharam. Ele estava executando o OS X e eu o Linux. Nenhum de nós está acostumado com os laptops travando - é uma coisa bastante rara no Linux e no OS X. Erros comuns de software podem ser descartados mais ou menos desde que estávamos rodando em sistemas operacionais diferentes (e isso não aconteceu durante um salto) segundo). Eu vim para atribuir esse evento à "radiação cósmica".

Mais tarde, "radiação cósmica" se tornou uma piada interna no meu local de trabalho. Sempre que algo acontece com nossos servidores e não podemos encontrar nenhuma explicação para isso, atribuímos brincando a falha à "radiação cósmica". :-)

Mais frequentemente, o ruído pode corromper os dados. As somas de verificação são usadas para combater isso em vários níveis; em um cabo de dados, normalmente há um bit de paridade que viaja ao lado dos dados. Isso reduz bastante a probabilidade de corrupção. Então, nos níveis de análise, os dados sem sentido são geralmente ignorados; portanto, mesmo que alguma corrupção tenha passado do bit de paridade ou de outras somas de verificação, na maioria dos casos, eles serão ignorados.

Além disso, alguns componentes são blindados eletricamente para bloquear o ruído (provavelmente não os raios cósmicos, eu acho).

Mas, no final, como disseram os outros respondentes, há um bit ou byte ocasional que é embaralhado, e resta a chance se esse é um byte significativo ou não. Na melhor das hipóteses, um raio cósmico embaralha um dos bits vazios e não tem absolutamente nenhum efeito ou trava o computador (isso é bom, porque o computador é impedido de causar danos); mas na pior das hipóteses, bem, tenho certeza que você pode imaginar.

Eu experimentei isso - não é raro que os raios cósmicos vire um pouco, mas é muito improvável que uma pessoa observe isso.

Eu estava trabalhando em uma ferramenta de compactação para um instalador em 2004. Meus dados de teste eram alguns arquivos de instalação da Adobe com cerca de 500 MB ou mais descompactados.

Após uma execução tediosa de compactação e uma descompactação para testar a integridade, o FC / B mostrou um byte diferente.

Dentro desse byte, o MSB inverteu. Eu também virei, me preocupando com um bug maluco que só surgiria sob condições muito específicas - eu nem sabia por onde começar a procurar.

Mas algo me disse para executar o teste novamente. Eu corri e passou. Configurei um script para executar o teste 5 vezes durante a noite. De manhã, todos os cinco haviam passado.

Então essa foi definitivamente uma virada cósmica.

Você também pode dar uma olhada no hardware tolerante a falhas.

Por exemplo, a Stratus Technology constrói servidores Wintel chamados ftServer, que tinham 2 ou 3 "placas-mãe" na etapa de bloqueio, comparando o resultado dos cálculos. (isso também é feito em veículos espaciais às vezes).

Os servidores Stratus evoluíram do chipset personalizado para o locktep no backplane.

Um sistema muito semelhante (mas de software) é a etapa de bloqueio da tolerância a falhas do VMWare com base no Hypervisor.

Como ponto de dados, isso aconteceu em nossa compilação:

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

Isso parece muito com um pouco de sorte acontecendo durante uma compilação, em um local muito significativo em um arquivo de origem por acaso.

Não estou necessariamente dizendo que se tratava de um "raio cósmico", mas o sintoma corresponde.