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


546

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?


42
„Zwycięskie loterie: jakie jest prawdopodobieństwo, że wpłyną one na program?”
kennytm

27
Zależy to częściowo od tego, gdzie program jest wykonywany i od tego, jak dobrze jest chroniony. Na Ziemi strumień promieniowania kosmicznego jest znacznie niższy niż w kosmosie, a nawet w pobliżu orbity Ziemi. Na przykład Kosmiczny Teleskop Hubble'a wytwarza surowe obrazy, które są pełne śladów promieni kosmicznych.
Adam Hollidge,

89
Czy to oznacza, że ​​odtąd, kiedy ktoś zapyta o finallybloki, będziemy musieli zakwalifikować go jako „zawsze wykonuje się, z wyjątkiem sytuacji, gdy program zakończy działanie lub zostanie uderzony promieniem kosmicznym”?
skaffman

72
Pracując nad prototypowym detektorem cząstek lata temu zaprogramowałem go do drukowania „ouch!” za każdym razem, gdy był uderzony przez promień kosmiczny. Dobre czasy ...
Beta

8
Jedno z najciekawszych pytań, które tu czytałem. Prawdziwy otwieracz do oczu. Licz na mnie, że otworzę ponownie.
Agnel Kurian

Odpowiedzi:


308

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.


10
Co ważniejsze, rozmiar funkcji układu dla procesorów w 1995 r. Wynosił około 0,35 µm lub 350 nm. Jest teraz 1/10 tego rozmiaru przy 35 nm.
Joe Koberg,

18
Czy to możliwe, że zamiast zmniejszać ryzyko, zmniejszony rozmiar zwiększyłby ryzyko, ponieważ zmiana stanu każdego bitu wymagałaby mniej energii?
Robert

63
Zmniejszony rozmiar zdecydowanie zwiększa ryzyko. Utwardzone procesory do pojazdów kosmicznych wykorzystują bardzo duże rozmiary funkcji, aby uniknąć efektów promieniowania kosmicznego.
Joe Koberg

22
Znacznie większym problemem są nie tylko promienie kosmiczne, ale również izotopy promieniotwórcze w materiałach zastosowanych w chipie. Twórcy dokładają wszelkich starań, aby krzem, lut, kapsułkowanie itp. Nie zawierały emiterów alfa lub beta.
Martin Beckett

14
Łał! Oznacza to, że około 1 bajt na moim komputerze ulega uszkodzeniu co dwa dni.
Stefan Monov

91

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 .


7
Dlaczego rosną wraz ze zmniejszaniem się rozmiaru chipa? Z pewnością mniejszy obiekt jest mniej narażony na uderzenie promieniem (tj. Porównaj rzucanie piłką tenisową w ścianę, do rzucania nią w znaczek)
Jonathan.

7
Ponieważ wraz ze zmniejszaniem się wielkości komponentów stają się one znacznie bardziej wrażliwe na uderzenia promieni kosmicznych.
ire_and_curses

4
Tak, mniejszy oznacza mniej prawdopodobne trafienie, ale bardziej prawdopodobne, że trafienie wpłynie na stan.
John Hascall,

2
@ire_and_curses [potrzebne źródło]
Anko

8
@Anko - To dość oczywiste. Ponieważ dany element staje się mniejszy, wymaga nieco mniejszego napięcia i mniejszego ładowania. To czyni go bardziej wrażliwym na wysadzenie go energią z kosmosu. Oto jednak odniesienie dla Ciebie: Gdy urządzenia pamięci LSI stają się mniejsze, stają się bardziej wrażliwe na uszkodzenia miękkie wywołane promieniowaniem jądrowym.
ire_and_curses

55

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.


9
Dodatkowy materiał z BH 2011 „Bitsquatting porwanie DNS bez eksploatacyjnych” media.blackhat.com/bh-us-11/Dinaburg/... list nowoczesne multi-GB pamięci DRAM mieć około 10000-30000 Fit / Mbit (mniej niż 100 godzin między błędy na każde 128 MB). W artykule wymieniono także artykuły, w których stwierdza się, że większość błędów miękkich pochodzi od promieniowania, prawie wszystkich przypadków - od promieni kosmicznych, a także niektórych przypadków od emiterów alfa wewnątrz komputera. Autorzy BH eksperymentowali i uzyskali 50000 dostępów do domen, zmieniając 1 bit od popularnych stron
osgx

Wyrazy uznania za dodanie tutaj najnowszych badań. Biorąc pod uwagę dynamikę głosowania SO i sposób ich kumulowania się w czasie, trudno jest mieć aktualną prezentację na ten temat (tutaj).
Fizz,

Mieliśmy podobny problem. Nie przeprowadziliśmy żadnych dokładnych badań, ale mieliśmy sporo zrzutów awaryjnych z widocznymi odwróconymi bitami. Sprawdziliśmy te bity i okazało się, że były w sekcji kodu. Porównaliśmy to, co powinno tam być i nie wyglądało to na celową modyfikację (tzn. Instrukcje wynikowe nie miały większego sensu). W końcu mieliśmy prostą aplikację, która porównywała zrzuty awarii z (zarchiwizowanymi) wydanymi wersjami i odfiltrowała takie przypadki. Co ciekawe, myślę, że większość takich przypadków pochodziła z Iranu, Arabii i myślę, że jeszcze jeden kraj z Ameryki Południowej (nie pamiętam teraz).
GiM,

2
W artykule Google wygląda to bardziej na przypadek, że część pamięci RAM jest zła. Około jednej trzeciej maszyn i ponad 8% modułów DIMM w naszej flocie widziało co najmniej jeden błąd, który można naprawić rocznie. Nasze współczynniki błędów korygujących w przeliczeniu na DIMM przekładają się na średnią 25 000–75 000 FIT (awarie czasu na miliard godzin pracy) na Mbit i medianę zakresu FIT 778–25 000 na Mbit (mediana dla DIMM z błędami), podczas gdy poprzednie badania podają 200–5 000 FIT na Mbit. Liczba możliwych do naprawienia błędów na moduł DIMM jest bardzo zmienna, przy czym niektóre moduły DIMM doświadczają ogromnej liczby błędów w porównaniu do innych.
vartec

31

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ą.


7
Prawdopodobieństwo odwrócenia bitu należy pomnożyć przez prawdopodobieństwo, że bit ma zauważalny wpływ na program. Zgaduję, że drugie prawdopodobieństwo jest znacznie niższe niż myślisz.
Mark Ransom,

2
@ Mark: Typowe programy komputerowe nie mają wbudowanej funkcji odporności na uszkodzenia. Jednobitowy błąd w kodzie programu najprawdopodobniej nie spowoduje awarii programu, jeśli uszkodzony kod zostanie wykonany.
Robert Harvey

75
Tak, ale większość pamięci zawiera dane, przy czym flip nie będzie taki visiblp.
zoul

34
@zoul. lol na 'visiblp', ale jeśli e = 1100101 ip = 1110000, to jesteś nieszczęśliwą ofiarą 3- bitowych przewrotów!
PaulG

10
@Paul: lub jeden palec.
mpen

30

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?


23
„Federalne organy regulacyjne badają, czy nagłe przyspieszenie w Toyocie jest powiązane z promieniami kosmicznymi”. Dlatego nigdy nie powinieneś dawać władzom federalnym władzy nad swoim życiem.

13
Sądzę, że teoria jest taka, że ​​promienie kosmiczne odbijają bity w starszych mózgach, powodując ich nieprawidłowe działanie i naciskanie niewłaściwego pedału.
Knox

16
"Widocznie"? Powiedziałbym, że w tym momencie to szalone przypuszczenie. Domyślam się, że zjawisko to jest wynikiem koszmaru systemów wbudowanych (właściwie najbardziej skomplikowanych systemów komputerowych) - wyścigu.
Michael Burr,

7
@ Knox: Wyjmij swój stary kapelusz z folii aluminiowej, jest przydatny!

3
To nie może być żart. Wcześniej widziałem takie naprawdę dziwne rzeczy. Nie tak rzadkie, jak myśli większość ludzi.
Brian Knoblauch,

25

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.


17

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.


Bitflipy z promieniem kosmicznym mogą nie być równomiernie rozmieszczone, szczególnie jeśli uwzględnimy burze słoneczne pod „zdarzeniami promieniowania kosmicznego” --umbrella. Jeśli masz dwa lub więcej bitflipów w tym samym bajcie, typowy ECC nie będzie w stanie poprawić błędu.
tobixen

@tobixen Wykrywanie błędu podwójnego bitu jest lepsze niż kontynuowanie działania ze złymi danymi. Następnym krokiem po ECC jest Chipkill z dublowaniem DIMM ...
Jan

13

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.


Bitflipy z promieniem kosmicznym mogą nie być równomiernie rozmieszczone, szczególnie jeśli uwzględnimy burze słoneczne pod „zdarzeniami promieniowania kosmicznego” --umbrella. Nagły wybuch może spowodować kilka bitów w bajcie, a algorytmy ECC nie będą w stanie naprawić awarii.
tobixen

12

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


Nie szukaj oprogramowania dla przepustnic. Czujniki i okablowanie przepustnic to słaby punkt. Mój czujnik pozycji przepustnicy Mitsubishi nie działał w generatorze liczb losowych ... Brak niezamierzonego przyspieszenia, ale na pewno nie zrobił nic dobrego dla mieszanki paliwowej!
Brian Knoblauch,

3
@Brian: Dobre oprogramowanie zorientowałoby się, że punkty danych były nieciągłe i doszło do wniosku, że dane są złe.
Robert Harvey

... a potem co ... Potrzebne są dobre dane. Świadomość, że to źle, nic nie pomaga. Nie można tego magicznie obejść.
Brian Knoblauch,

3
@Brian: Po pierwsze, możesz podjąć działania naprawcze w oparciu o wiedzę, że twoje dane są złe. Możesz na przykład przestać przyspieszać.
Robert Harvey

Tak, możesz (i powinieneś) sprawdzać dane. Najlepszy kompleksowy. Zmniejsza to jednak tylko ryzyko korupcji. Wyobraź sobie, że twoja instrukcja „is this valid” powoduje uszkodzenie bitu w pamięci lub rejestrze procesora właśnie wtedy, gdy chcesz rozgałęzić się do modułu obsługi błędów.
eckes

11

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.


8
Nad atmosferą dzieją się dwie rzeczy: 1) całkowity strumień jest wyższy 2) znacznie więcej ma postać ciężkich, bardzo energetycznych cząstek (z wystarczającą ilością energii, aby trochę przerzucić nieco na małą przestrzeń).
dmckee --- były moderator kociak

Jeśli chodzi o referencje, istnieją książki (np. Books.google.com/books?hl=pl&lr=&id=Er5_rzW0q3MC ), konferencje (np. Radecs2015.org , seekapld.org i inne) oraz mnóstwo artykułów na ten temat . Promienie kosmiczne nie są żartem w kosmosie. Są one jednym z głównych powodów, dla których wiele statków kosmicznych korzysta z komputerów zahartowanych radem, z których większość ma moc przetwarzania nowoczesnego inteligentnego piekarnika tostowego.
David Hammen

8

„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”. :-)


7

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ć.


Bitflipy z promieniem kosmicznym mogą nie być równomiernie rozmieszczone, szczególnie jeśli uwzględnimy burze słoneczne pod „zdarzeniami promieniowania kosmicznego” --umbrella. Jeśli masz dwa klipy bitowe w tym samym bajcie, sprawdzenie bitu parzystości zakończy się niepowodzeniem. Kilka bitflipów i algorytmy ECC prawdopodobnie nie będą w stanie naprawić awarii.
tobixen

5

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.


Zdecydowanie? Czy nie mogła to być niezainicjowana zmienna, która nigdy nie uzyskała złej wartości początkowej w kolejnych testach?
doug65536

Zawsze kompiluję z W3 lub W4 na VS - także Rational Purify, nie było żadnych błędów tego rodzaju.
rep_movsd

Ach, przepraszam, nie wiedziałem, że te opcje kompilatora i Rational Purify były całkowicie nieomylne. =)
doug65536

Biorąc pod uwagę, że kod został następnie wprowadzony do produkcji oraz odpowiednio skompresowany i nieskompresowany setek GB, nie było śladu podobnego błędu.
rep_movsd

4

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.


4

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ą.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.