Promienie kosmiczne: jakie jest prawdopodobieństwo, że wpłyną one na program?

Najwyraźniej nie bez znaczenia. Z tego artykułu New Scientist , cytat ze zgłoszenia patentowego Intela:

" wystąpiły awarie komputerów wywołane promieniami kosmicznymi i oczekuje się, że będą rosły wraz z częstotliwością, ponieważ urządzenia (na przykład Tranzystory) zmniejszają rozmiar chipów. Przewiduje się, że problem ten stanie się głównym ogranicznikiem niezawodności komputera w następnej dekadzie. "

Możesz przeczytać Pełny patent tutaj .

Uwaga: Ta odpowiedź Nie dotyczy fizyki, ale błędów cichej 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ń awarii pamięci ECC na dużych farmach serwerów, takich jak klastry CERN i centra danych Google. Sprzęt klasy serwerowej z ECC może wykrywać i korygować wszystkie błędy pojedynczego bitu oraz wykrywać wiele błędów wielobitowych.

Możemy założyć, że istnieje wiele komputerów bez ECC (oraz smartfonów mobilnych innych niż ECC). Jeśli sprawdzimy dokumenty pod kątem ECC-correctable error rates( single bitflips), możemy poznać szybkość uszkodzeń cichej pamięci w pamięci innej niż ECC.

• Badanie CERN 2007 Na Dużą Skalę "integralność danych" : dostawcy deklarują " współczynnik błędów bitowych 10^-12 dla modułów pamięci", "obserwowany poziom błędu jest o 4 rzędy wielkości niższy niż oczekiwany". W przypadku zadań wymagających dużej ilości danych (8 GB/s odczytu pamięci) oznacza to, że pojedynczy bit flip może wystąpić co minutę (10^-12 Ber) lub raz na dwa dni (10^-16 BER).

• 2009 artykuł Google "DRAM Errors in the Wild: a Large-Scale Field Study" mówi, że może być do 25000-75000 JEDNOBITOWEGO dopasowania na Mbit (awarie w czasie na miliard godzin), co jest równe 1 - 5 bitowych błędów na godzinę dla 8GB PAMIĘCI RAM po moich obliczeniach. Papier mówi to samo: "średni skorygowany poziom błędów 2000-6000 na GB na rok ".

• 2012 Sandia report " wykrywanie i korekcja uszkodzeń cichych danych dla dużych obliczeń o wysokiej wydajności ":" podwójne przeloty bitowe uznano za mało prawdopodobne", ale w gęstym Cray XT5 firmy ORNL są one" w tempie jednego dziennie dla ponad 75 000 DIMM " nawet z ECC. A błędy pojedynczych bitów powinny być wyższe.

Tak więc, jeśli program ma duży zbiór danych (kilka GB) lub ma wysoką szybkość odczytu lub zapisu pamięci (GB / s lub więcej) i działa przez kilka godzin, wtedy możemy spodziewać się do kilku cichych bitów na sprzęcie stacjonarnym. Szybkość ta nie jest wykrywalna przez memtest, a Moduły DRAM są dobre.

Long cluster działa na tysiącach komputerów innych niż ECC, jak BOINC Internet wide grid computing zawsze będzie miał błędy z BiT-flip pamięci, a także z cichych błędów dyskowych i sieciowych.

A dla większych maszyn (10 tysięcy serwerów) nawet z ochroną ECC przed błędami jednobitowymi, jak widzimy w raporcie Sandia 2012, mogą być double-bit obraca się każdego dnia, więc nie będziesz miał szansy uruchomić pełnowymiarowego programu równoległego przez kilka dni(bez regularnego checkpointingu i ponownego uruchamiania z ostatniego dobrego checkpointa w przypadku podwójnego błędu). Ogromne maszyny otrzymają również bit-flipy w swoich buforach i rejestrach procesora (zarówno architektonicznych, jak i wewnętrznych wyzwalaczy chipów, np. w Alu datapath), 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 nowy DRAM do laptopa, który zmarł kilka tygodni później. Zaczęło dawać wiele błędów pamięci. Co dostaję: Laptop się zawiesza, Linux restartuje, uruchamia fsck, znajduje błędy na głównym systemie plików i mówi, że chce zrobić restart po poprawieniu błędów. Ale przy każdym następnym restarcie (zrobiłem około 5-6 z nich) nadal są błędy znalezione na głównym systemie plików.

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

Z drugiej strony, ludzie mówią o prawdopodobieństwa w przypadku scenariuszy oprogramowania zazwyczaj nie mają pojęcia, o czym mówią.

Cóż, promieniowanie kosmiczne najwyraźniej spowodowało 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żna skorygować 1-bitowe błędy promieniowania kosmicznego. 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 nie ma dwóch komórek obok siebie. Zjawisko promieniowania kosmicznego, które wpływa na dwie komórki, spowoduje zatem dwa poprawialne błędy 1-bitowe.

Sun stwierdza: (Część nr 816-5053-10 kwietnia 2002)

Ogólnie rzecz biorąc, w pamięci DRAM występują błędy soft promieni kosmicznych w stawka od ~10 do 100 FIT / MB (1 FIT = 1 urządzenie ulegnie awarii 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 ze 100 GB pokazywałby Zdarzenie co 100 do 1000 godzin. Jest to jednak przybliżona ocena, która pozwoli zmiana w funkcji opisanych powyżej efektów.

Błędy pamięci są prawdziwe, a pamięć ECC pomaga. Poprawnie zaimplementowana pamięć ECC poprawi błędy pojedynczego bitu i wykryje błędy podwójnego bitu (zatrzymanie systemu w przypadku wykrycia takiego błędu.) Widać to po tym, jak regularnie ludzie narzekają na to, co wydaje się być problemem oprogramowania, który jest rozwiązywany przez uruchomienie Memtest86 i odkrywanie złej pamięci. Oczywiście przemijająca awaria spowodowana promieniowaniem kosmicznym różni się od konsekwentnie zawodzącej części pamięci, ale jest związane z szerszym pytaniem, na ile należy ufać swojej pamięci, aby działała prawidłowo.

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

Ciekawy link: http://cr.yp.to/hardware/ecc.html

Link Corsair na stronie niestety wydaje się martwy.

Jeśli program jest krytyczny dla życia (zabije kogoś, jeśli zawiedzie), musi być napisany w taki sposób, aby albo był bezpieczny, albo odzyskał się automatycznie po takiej awarii. Wszystkie inne programy, YMMV.

Toyoty są przykładem. Mów co chcesz o kablu przepustnicy, ale to jest , a nie oprogramowanie.

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

Kiedyś zaprogramowałem urządzenia, które miały latać w kosmosie, a potem (podobno nikt nie pokazał mi na ten temat papieru, ale mówiono, że jest to powszechna wiedza w biznesie) można było oczekiwać, że promienie kosmiczne będą wywoływać błędy cały czas.

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

Na przykład zauważ, że części Intela przeznaczone do" wbudowanych " aplikacji mają tendencję do dodawania ECC do arkusza specyfikacji. Bay Trail dla tabletu go brakuje, ponieważ uczyniłoby to pamięć nieco droższą i prawdopodobnie wolniejszą. A jeśli tablet zawiesza program raz na niebieskim księżycu, użytkownik nie dba zbytnio. Samo oprogramowanie jest znacznie mniej niezawodny niż HW i tak. Ale dla SKU przeznaczonych do użytku w maszynach przemysłowych i motoryzacji, ECC jest obowiązkowe. Od tego momentu spodziewamy się, że oprogramowanie SW będzie znacznie bardziej niezawodne, a błędy wynikające z losowych awarii będą 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), jak i obsługę błędów w czasie wykonywania, która próbuje odzyskać błędy wykryte przez ECC, oraz często również zadania scrubber pamięci, które przechodzą i czytać i zapisywać pamięć w sposób ciągły, aby upewnić się, że wszelkie błędy, które występują, zostaną zauważone.

Ale dla głównego nurtu oprogramowania PC? Nic wielkiego. Na długo żyjący serwer? Użyj ECC i obsługi błędów. Jeśli błąd nie do usunięcia zabije jądro, niech tak będzie. Albo Popadasz w paranoję i używasz redundantnego systemu z blokadą, aby Jeśli jeden rdzeń zostanie uszkodzony, drugi może przejąć kontrolę podczas ponownego uruchamiania pierwszego rdzenia.

Coraz częściej szum może uszkodzić dane. sumy kontrolne są używane do walki z tym na wielu poziomach; w kablu danych zazwyczaj występuje bit parzystości , który podróżuje obok danych. Toznacznie zmniejsza prawdopodobieństwo korupcji. Następnie na poziomach parsowania nonsensowne dane są zazwyczaj ignorowane, więc nawet jeśli jakaś korupcja ominie bit parzystości lub inne sumy kontrolne, w większości przypadków będą ignorowane.

Ponadto niektóre elementy są ekranowane elektrycznie do Zablokuj hałas (chyba nie promienie kosmiczne).

Ale w końcu, jak powiedzieli inni odpowiadający, istnieje sporadyczny bit lub bajt, który zostaje zaszyfrowany, i pozostaje przypadkowe, czy jest to znaczący bajt, czy nie. W najlepszym wypadku, promień kosmiczny rozszyfruje jeden z pustych bitów i nie ma absolutnie żadnego efektu, lub zawiesza komputer (to dobra rzecz, ponieważ komputer jest powstrzymywany przed wyrządzeniem szkody); ale w najgorszym przypadku, Cóż, jestem pewien, że możesz sobie wyobrazić.

"zdarzenia promieniowania kosmicznego" są uważane za jednorodne w wielu odpowiedziach tutaj, może to nie zawsze być prawdą (np. supernowe). Chociaż "promienie kosmiczne" z definicji (przynajmniej według Wikipedii) pochodzą z zewnętrznej przestrzeni, myślę, że należy również uwzględnić lokalne burze słoneczne (aka koronalne wyrzucanie masy pod tym samym parasolem. Uważam, że może to spowodować, że kilka bitów odwróci się w krótkim czasie, potencjalnie wystarczająco, aby uszkodzić nawet ECC-enabled pamięć.

Jakieś 10 lat temu siedziałem tuż obok innego faceta, siedzieliśmy z każdym laptopem, to był okres z dość "burzową" pogodą słoneczną(siedząc w Arktyce, mogliśmy to zaobserwować pośrednio - wiele zorzy polarnej do zobaczenia). Nagle - w w tej samej chwili-oba nasze laptopy się zepsuły. On działał na OS X, a ja na Linuksie. Żaden z nas nie jest przyzwyczajony do awarii laptopów - jest to dość rzadka rzecz na Linuksie i OS X. typowe błędy oprogramowania można mniej lub bardziej wykluczyć, ponieważ działaliśmy na różnych systemach operacyjnych (i nie stało się to podczas sekundy przestępnej). Przyszedłem przypisać to wydarzenie "promieniowaniu kosmicznemu".

Później "promieniowanie kosmiczne" stało się wewnętrznym żartem w moim miejscu pracy. Ilekroć coś się dzieje z naszym serwery i nie możemy znaleźć na to żadnego wyjaśnienia, żartobliwie przypisujemy tę winę "promieniowaniu kosmicznemu". :-)

Doświadczyłem tego - promieniowanie kosmiczne nie jest rzadkością, ale jest bardzo mało prawdopodobne, aby ktoś to zaobserwował.

Pracowałem nad narzędziem kompresji dla instalatora w 2004 roku. Moje dane testowe były niektóre pliki instalacyjne Adobe około 500 MB lub więcej dekompresowane.

Po żmudnej kompresji i dekompresji w celu przetestowania integralności, FC / B wykazał jeden bajt inny.

W tym jednym bajcie MSB się przewróciło. Też się przewróciłem, martwiąc się, że miałem szalonego robaka, który wynurzył się tylko w bardzo specyficznych warunkach - nawet nie wiedziałem, od czego zacząć szukać.

Ale coś mi kazało powtórzyć test. Sprawdziłam to i przeszło. Skonfigurowałem skrypt, aby uruchomić test 5 razy na noc. Nad ranem minęły wszystkie 5.

Więc to było zdecydowanie kosmiczne odbicie bitowe.

Możesz też rzucić okiem na sprzęt odporny na błędy.

Na przykład Technologia Stratus buduje Serwery Wintel o nazwie ftServer, które miały 2 lub 3 "Płyty główne" w kroku blokującym, porównując wynik obliczeń. (zdarza się to także w pojazdach kosmicznych).

Serwery Stratus ewoluowały z niestandardowego chipsetu do lockstep na backplane.

Bardzo podobnym (ale programowym) systemem jest blokada VMware Fault Tolerance oparta na hipernadzorcy.

Jako punkt danych, stało się to 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  - ^

To wygląda bardzo mocno jak bitowe odwrócenie podczas kompilacji, w bardzo znaczącym miejscu w pliku źródłowym przez przypadek.