Cosmic Rays: jakie jest prawdopodobieństwo, że wpłyną na program?

Po raz kolejny byłem w trakcie przeglądu projektu i spotkałem się z twierdzeniem, że prawdopodobieństwo określonego scenariusza było „mniejsze niż ryzyko promieniowania kosmicznego” wpływającego na program, i przyszło mi do głowy, że nie miałem najmniejszego pojęcia, co to prawdopodobieństwo jest.

„Ponieważ 2 ^-128 to 1 na 340282366920938463463374607431768211456, myślę, że mamy uzasadnione szanse, nawet jeśli obliczenia te są wyłączone z kilku miliardów razy ... Jesteśmy znacznie bardziej narażeni na promieniowanie kosmiczne spieprz nas, jak sądzę. ”

Czy ten programator jest poprawny? Jakie jest prawdopodobieństwo, że promień kosmiczny uderzy w komputer i wpłynie na wykonanie programu?

Z Wikipedii :

Badania przeprowadzone przez IBM w latach 90. sugerują, że komputery zwykle napotykają około jednego błędu wywołanego promieniowaniem kosmicznym na 256 megabajtów pamięci RAM na miesiąc. ^[15]

Oznacza to, że prawdopodobieństwo 3,7 x 10 ^-9 na bajt na miesiąc, lub 1,4 x 10 ^-15 na bajt na sekundę. Jeśli Twój program działa przez 1 minutę i zajmuje 20 MB pamięci RAM, prawdopodobieństwo błędu byłoby

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

Sprawdzanie błędów może pomóc ograniczyć następstwa awarii. Ponadto, z uwagi na bardziej kompaktowy rozmiar układów, jak komentuje Joe, wskaźnik awaryjności może być inny niż 20 lat temu.

Najwyraźniej nie bez znaczenia. Z tego artykułu New Scientist cytat z wniosku patentowego Intela:

„Wystąpiły awarie komputera wywołane promieniowaniem kosmicznym i oczekuje się, że będą rosły wraz z częstotliwością, ponieważ urządzenia (na przykład tranzystory) zmniejszają rozmiar układów scalonych. Przewiduje się, że problem ten stanie się głównym ograniczeniem niezawodności komputera w następnej dekadzie”.

Możesz przeczytać pełny patent tutaj .

Uwaga: ta odpowiedź nie dotyczy fizyki, ale cichych błędów pamięci w modułach pamięci innych niż ECC. Niektóre błędy mogą pochodzić z kosmosu, a niektóre z wewnętrznej przestrzeni pulpitu.

Istnieje kilka badań dotyczących awarii pamięci ECC w dużych farmach serwerów, takich jak klastry CERN i centra danych Google. Sprzęt klasy serwerowej z ECC może wykrywać i poprawiać wszystkie błędy bitów oraz wykrywać wiele błędów bitów.

Możemy założyć, że istnieje wiele komputerów stacjonarnych spoza ECC (i smartfonów spoza ECC). Jeśli sprawdzimy dokumenty pod kątem współczynników błędów, które można skorygować za pomocą ECC (pojedyncze bitflipy), możemy poznać współczynnik cichego uszkodzenia pamięci w pamięci innej niż ECC.

• Badanie CERN 2007 na dużą skalę „Integralność danych” : dostawcy deklarują „ współczynnik błędu bitowego ^10–12 dla swoich modułów pamięci ”, „ zaobserwowany poziom błędu jest o 4 rzędy wielkości niższy niż oczekiwano ”. W przypadku zadań wymagających dużej ilości danych (8 GB / s odczytu pamięci) oznacza to, że pojedyncza zmiana bitów może występować co minutę ( ^10-12 BER dostawców) lub raz na dwa dni ( ^10-16 BER).

• Artykuł Google 2009 „DRAM Errors in the Wild: A Large-Scale Field Study” mówi, że może istnieć do 25000-75000 jednobitowych FIT na Mbit ( awarie czasu na miliard godzin ), co jest równe 1 - 5 bitów błędów na godzinę dla 8 GB pamięci RAM po moich obliczeniach. Papier mówi to samo: „ oznacza możliwe do skorygowania poziomy błędów 2000–6000 na GB rocznie ”.

• Raport Sandia z 2012 r. „Wykrywanie i korygowanie cichego uszkodzenia danych w obliczeniach wielkoskalowych o wysokiej wydajności” : „podwójne odwrócenie bitów uznano za mało prawdopodobne”, ale w gęstej matrycy Cray XT5 firmy ORNL są one „w tempie jednego dnia dla 75 000+ modułów DIMM”, nawet z ECC. Błędy jednobitowe powinny być wyższe.

Tak więc, jeśli program ma duży zestaw danych (kilka GB) lub ma wysoką szybkość odczytu lub zapisu w pamięci (GB / s lub więcej) i działa przez kilka godzin, możemy spodziewać się nawet kilku cichych bitów na sprzęcie komputerowym. Ta szybkość nie jest wykrywana przez memtest, a moduły DRAM są dobre.

Długi klaster działa na tysiącach komputerów nieobsługujących ECC, takich jak sieci grid BOINC w Internecie zawsze będą miały błędy wynikające z odwracania bitów pamięci, a także z cichych błędów dysku i sieci.

A w przypadku większych maszyn (10 tysięcy serwerów), nawet z ochroną ECC przed błędami jednobitowymi, jak widzimy w raporcie Sandii z 2012 roku, każdego dnia mogą występować podwójne bity, więc nie będziesz mieć szansy na uruchomienie równoległego pełnego rozmiaru program na kilka dni (bez regularnego sprawdzania i restartowania od ostatniego dobrego punktu kontrolnego w przypadku podwójnego błędu). Ogromne maszyny również będą miały bit-flipy w swoich pamięciach podręcznych i rejestrach procesora (wyzwalacze zarówno architektoniczne, jak i wewnętrzne chipów, np. W ścieżce danych ALU), ponieważ nie wszystkie z nich są chronione przez ECC.

PS: Będzie znacznie gorzej, jeśli moduł DRAM będzie zły. Na przykład zainstalowałem nową pamięć DRAM w laptopie, który zmarł kilka tygodni później. Zaczęło dawać dużo błędów pamięci. Co otrzymuję: laptop zawiesza się, restartuje Linux, uruchamia fsck, znajduje błędy w głównym systemie plików i mówi, że chce zrestartować się po naprawieniu błędów. Ale przy każdym ponownym uruchomieniu (zrobiłem ich około 5-6) nadal występują błędy w głównym systemie plików.

Wikipedia cytuje badanie przeprowadzone przez IBM w latach 90. sugerujące, że „komputery zwykle doświadczają około jednego błędu wywołanego promieniowaniem kosmicznym na 256 megabajtów pamięci RAM miesięcznie”. Niestety cytat dotyczył artykułu w Scientific American, w którym nie podano żadnych dalszych odniesień. Osobiście uważam, że liczba ta jest bardzo wysoka, ale być może większość błędów pamięci wywołanych przez promienie kosmiczne nie powoduje żadnych faktycznych lub zauważalnych problemów.

Z drugiej strony ludzie rozmawiający o prawdopodobieństwach dotyczących scenariuszy oprogramowania zazwyczaj nie mają pojęcia, o czym mówią.

Cóż, promienie kosmiczne najwyraźniej spowodowały awarię elektroniki w samochodach Toyoty, więc powiedziałbym, że prawdopodobieństwo jest bardzo wysokie :)

Czy promienie kosmiczne naprawdę powodują nieszczęścia Toyoty?

Za pomocą ECC możesz poprawić 1-bitowe błędy Kosmicznych Promieni. Aby uniknąć 10% przypadków, w których promienie kosmiczne powodują błędy 2-bitowe, komórki ECC są zwykle przeplatane przez chipy, więc żadne dwie komórki nie są obok siebie. Zdarzenie promienia kosmicznego, które wpływa na dwie komórki, spowoduje zatem dwa korygowane błędy 1-bitowe.

Słońce stwierdza: (część nr 816-5053-10 kwietnia 2002)

Mówiąc ogólnie, błędy miękkiego promieniowania kosmicznego występują w pamięci DRAM z częstotliwością ~ 10 do 100 FIT / MB (1 FIT = 1 awaria urządzenia w ciągu 1 miliarda godzin). Tak więc system z 10 GB pamięci powinien pokazywać zdarzenie ECC co 1000 do 10 000 godzin, a system z 100 GB pokazywałby zdarzenie co 100 do 1000 godzin. Jest to jednak przybliżone oszacowanie, które zmieni się w zależności od opisanych powyżej efektów.

Błędy pamięci są prawdziwe, a pamięć ECC pomaga. Prawidłowo zaimplementowana pamięć ECC poprawi błędy pojedynczych bitów i wykryje błędy podwójnych bitów (zatrzymanie systemu, jeśli taki błąd zostanie wykryty). Widać to na podstawie tego, jak często ludzie narzekają na to, co wydaje się problemem z oprogramowaniem, który jest rozwiązywany przez uruchomienie Memtest86 i odkrywanie złej pamięci. Oczywiście przejściowa awaria spowodowana przez promień kosmiczny różni się od konsekwentnie zawodzącego fragmentu pamięci, ale ma znaczenie dla szerszego pytania, na ile powinieneś ufać swojej pamięci, aby działać poprawnie.

Analiza oparta na rozmiarze rezydenta 20 MB może być odpowiednia dla trywialnych aplikacji, ale duże systemy rutynowo mają wiele serwerów z dużymi pamięciami głównymi.

Interesujący link: http://cr.yp.to/hardware/ecc.html

Link do strony Corsair na stronie wydaje się niestety martwy.

To prawdziwy problem i dlatego pamięć ECC jest używana w serwerach i systemach wbudowanych. I dlaczego systemy latające różnią się od systemów naziemnych.

Na przykład zauważ, że części Intela przeznaczone do aplikacji „osadzonych” zwykle dodają ECC do arkusza specyfikacji. Brakuje go w Bay Trail na tablet, ponieważ spowodowałoby to, że pamięć byłaby nieco droższa i być może wolniejsza. A jeśli tablet zawiesza program raz na niebieskim księżycu, użytkownik nie dba o to. Samo oprogramowanie i tak jest znacznie mniej niezawodne niż HW. Jednak w przypadku jednostek SKU przeznaczonych do stosowania w maszynach przemysłowych i motoryzacyjnych ECC jest obowiązkowe. Ponieważ tutaj spodziewamy się, że SW będzie o wiele bardziej niezawodny, a błędy z przypadkowych zakłóceń byłyby prawdziwym problemem.

Systemy certyfikowane zgodnie z IEC 61508 i podobnymi standardami zwykle mają zarówno testy rozruchowe, które sprawdzają, czy cała pamięć RAM działa (brak bitów zatrzymanych na zero lub jeden), a także obsługę błędów w środowisku wykonawczym, które próbuje odzyskać po błędach wykrytych przez ECC, oraz często także zadania płuczki pamięci, które przechodzą i odczytują i zapisują pamięć w sposób ciągły, aby upewnić się, że wszelkie występujące błędy zostaną zauważone.

Ale w przypadku głównego oprogramowania komputerowego? Żaden problem. Dla długowiecznego serwera? Użyj ECC i procedury usuwania błędów. Jeśli nie dający się naprawić błąd zabija jądro, niech tak będzie. Albo wpadniesz w paranoję i używasz nadmiarowego systemu z blokadą, aby w przypadku uszkodzenia jednego rdzenia drugi mógł przejąć kontrolę podczas pierwszego uruchamiania rdzenia.

Jeśli program ma krytyczne znaczenie dla życia (zabije kogoś, jeśli zawiedzie), należy go napisać w taki sposób, aby był bezpieczny w razie awarii lub automatycznie wyszedł z takiej awarii. Wszystkie inne programy, YMMV.

Przykładem są toyoty. Mów co chcesz o kablu przepustnicy, ale to nie jest oprogramowanie.

Zobacz także http://en.wikipedia.org/wiki/Therac-25

Kiedyś programowałem urządzenia, które miały latać w kosmosie, a potem (podobno nikt nigdy nie pokazał mi na ten temat żadnej gazety, ale podobno wiadomo w branży) można oczekiwać, że promienie kosmiczne będą przez cały czas wywoływać błędy.

„zdarzenia promienia kosmicznego” są uważane za mające jednolity rozkład w wielu odpowiedziach tutaj, nie zawsze może to być prawda (tj. supernowe). Mimo, że „promieniowanie kosmiczne” z definicji (przynajmniej według Wikipedii) pochodzi z zewnętrznej przestrzeni, myślę, że uczciwie jest także lokalnych burz słonecznych (aka koronalny wyrzut masy pod jednym parasolem. Wierzę, że może to powodować wiele bitów, aby odwrócić w ciągu krótki okres czasu, potencjalnie wystarczający do uszkodzenia nawet pamięci obsługującej ECC.

Powszechnie wiadomo, że burze słoneczne mogą spowodować pewne spustoszenie w systemach elektrycznych (takich jak Awaria zasilania w Quebecu w marcu 1989 r .). Jest całkiem prawdopodobne, że może to mieć wpływ na systemy komputerowe.

Jakieś 10 lat temu siedziałem obok innego faceta, siedzieliśmy z każdym z naszych laptopów, to był okres z dość „burzową” pogodą słoneczną (siedząc w Arktyce, mogliśmy to zaobserwować pośrednio - dużo zorzy polarnej do być widzianym). Nagle - w tej samej chwili - oba nasze laptopy uległy awarii. Miał OS X, a ja Linux. Żadne z nas nie jest przyzwyczajone do awarii laptopów - jest to dość rzadka rzecz w systemach Linux i OS X. Częste błędy oprogramowania można mniej więcej wykluczyć, ponieważ działaliśmy na różnych systemach operacyjnych (i nie zdarzyło się to podczas skoku druga). Przyszedłem przypisywać to wydarzenie „promieniowaniu kosmicznemu”.

Później „promieniowanie kosmiczne” stało się wewnętrznym żartem w moim miejscu pracy. Ilekroć coś dzieje się z naszymi serwerami i nie możemy znaleźć żadnego wytłumaczenia, żartobliwie przypisujemy usterkę „promieniowaniu kosmicznemu”. :-)

Częściej hałas może uszkodzić dane. Sumy kontrolne służą do zwalczania tego na wielu poziomach; w kablu danych zwykle znajduje się bit parzystości, który przemieszcza się wzdłuż danych. To znacznie zmniejsza prawdopodobieństwo uszkodzenia. Następnie na poziomach analizowania dane nonsensowne są zwykle ignorowane, więc nawet jeśli pewne uszkodzenie przekroczyłoby bit parzystości lub inne sumy kontrolne, w większości przypadków zostanie zignorowane.

Ponadto niektóre elementy są elektrycznie ekranowane, aby blokować hałas (prawdopodobnie nie promienie kosmiczne).

Ale w końcu, jak powiedzieli inni autorzy, od czasu do czasu zdarza się, że bit lub bajt zostaje zakodowany, i pozostaje przypadkowi, czy jest to znaczący bajt, czy nie. Najlepszy scenariusz, promień kosmiczny przedziera się przez jeden z pustych bitów i nie ma absolutnie żadnego efektu ani nie powoduje awarii komputera (jest to dobra rzecz, ponieważ komputer nie może wyrządzić szkody); ale w najgorszym przypadku jestem pewien, że możesz to sobie wyobrazić.

Doświadczyłem tego - promieniowanie kosmiczne nie jest rzadkie, ale bardzo mało prawdopodobne jest, aby ktoś to zauważył.

Pracowałem nad narzędziem do kompresji dla instalatora w 2004 roku. Moje dane testowe to niektóre pliki instalacyjne Adobe o wielkości około 500 MB lub więcej zdekompresowane.

Po żmudnym cyklu kompresji i dekompresji w celu przetestowania integralności FC / B pokazał jeden bajt inny.

W tym bajcie MSB przerzucił. Odwróciłem się również, martwiąc się, że mam szalonego robaka, który pojawiłby się tylko w bardzo szczególnych warunkach - nawet nie wiedziałem, od czego zacząć.

Ale coś kazało mi ponownie uruchomić test. Uruchomiłem to i minęło. Skonfigurowałem skrypt, aby uruchomić test 5 razy w ciągu nocy. Rano wszystkie 5 minęło.

To był zdecydowanie kosmiczny bit.

Możesz także przyjrzeć się sprzętowi odpornemu na awarie.

Na przykład Stratus Technology buduje serwery Wintel o nazwie ftServer, które miały 2 lub 3 „płyty główne” w kroku blokowania, porównując wyniki obliczeń. (czasami dzieje się tak również w pojazdach kosmicznych).

Serwery Stratus ewoluowały od niestandardowego mikroukładu po blokadę na płycie montażowej.

Bardzo podobny (ale programowy) system to blokada tolerancji błędów VMWare oparta na Hypervisoru.

Jako punkt danych stało się to po prostu na naszej kompilacji:

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

Wygląda to bardzo silnie, jak przypadkowe odwrócenie podczas kompilacji, w bardzo znaczącym miejscu w pliku źródłowym przez przypadek.

Niekoniecznie mówię, że był to „promień kosmiczny”, ale symptomy pasują.