Vlákno názorů k článku Statické a dynamické paměti od Stanislav Brabec - Jak se měkkým chybám předchází? Použitím modulů s...
-
Kvakor (neregistrovaný)K mekkym chybam: Existuji pameti s ECC (viz http://en.wikipedia.org/wiki/ECC_memory#Error-correcting_memory ), ktere jednobitove chyby opravuji a vicebitove alespon detekuji. Pouzivaji se v serverech (obzvlast na tech, kde je bezny uptime roky) a v kosmu, kde je toho zareni ponekud vice ...
K afsa casticim: ony nemusi proniknout pouzdrem. Ony mohou vznikonout primo v nem - alfa zarice (jako uran a thorium) nejsou az tak vzacne kovy a mohou se obevit i v materialu onoho pouzdra (obzvlas to platilo u tech keramickych). Viz http://www.catb.org/jargon/html/C/cosmic-rays.html -
Rejpal (neregistrovaný)No tak pouze jednobitové opravy by byly v kosmu úplně k ničemu, to by ten raketoplán brzo spadnul. :-) Pokud se nepletu, jejich telemetrie historicky (tedy od okamžiku nahrazení feritových pamětí raketoplánu polovodičovými v roce 1991) již zaznamenala v polovodičové paměti počítačů AP-101S i dvaceti- až třicetibitové (!) chyby. (A samozřejmě opravila.)
-
A co paměti bez ECC? Je tam ještě nějaká další ochrana, nebo rovnou selžou? Pokud selžou, tak by na to musel několik dnů běžící memtest nebo spící notebook občas narazit.
Právě zářiče v materiálu pouzdra jsem měl na mysli. To by znamenalo, že výrobce, který dokáže materiály použité k výrobě čipů a pouzer lépe vyčistit od alfa zářičů, bude mít méně chybující DRAM. -
Pavel TišnovskýZlatý podporovatelPodle všeho se u DRAM čistí materiál použitý jako obal + se mohou přidávat další bity sloužící pro korekci (Reed-Solomonovy kódy atd). Ovšem pochybuji, že se to v běžných DRAM (používaných v PC) implementuje, to by se tím přece někdo chlubil. Všude je pouze vidět kapacita+rychlost vystavení dat v synchro režimu, žádný MTFB.
http://en.wikipedia.org/wiki/Soft_error -
Pavel TišnovskýZlatý podporovatelNo Seymour Cray prohlásil něco na způsob, že "kontrola parity je pro vidláky" (aspoň si tak překládám farmers) :-) Jednobitové ECC jsou trošku lepší, ale problém je, že při větší spršce alfa záření se chyba rozleze i do okolních buněk, takže je v kritických aplikacích lepší používat něco na způsob podélné a příčné ECC (přes řádky a sloupce).
-
Rejpal (neregistrovaný)
že při větší spršce alfa záření se chyba rozleze i do okolních buněk, takže je v kritických aplikacích lepší používat něco na způsob podélné a příčné ECC (přes řádky a sloupce).
Ona stačí i jen jedna hmotná nabitá částice. Našel jsem ten paper NASA, o kterém jsem mluvil výše - Single Event Upsets for Space Shuttle Flights of New General Purpose Computer Memory Devices. Pamatoval jsem si to špatně, nejvíc v té době (mezi roky 91-94) zaznamenali jen 14bitovou chybu - ale zase je možné, že jsem v nějakém pozdějším materiálu našel vyšší číslo a mezitím zapomněl, kde ty materiály jsou, ale teď vážně nevím, kde bych to měl hledat.
Každopádně zaznamenali maximální chybu minimálně (:-)) čtrnáct bitů. A ten subsystém funguje přesně tak, jak popisuješ - opravná slova jsou svými bity co nejvíc "rozprostřena" (myslím, že skoro náhodně po celé krabici s čipy, aby tu bezpečnost proti částicím měli fakt izotropní), aby i mnohobitová chyba nezpůsobila neopravitelnost kvůli poškození více bitů v jediném slově. Údajně většina vícebitových chyb byla lokalizována na jediný čip, takže se rozprostření opravného kódu přes čipy ukázalo jako velice rozumné. Vychází mi, že na raketoplánu v té době docházelo k jedné "mimořádné události" :-) každých zhruba dvě a půl hodiny.
Díky velmi precizní telemetrii, kterou běžné servery (ani ty s ECC ;-)) vybaveny nejsou, tak získala NASA díky tisícům zaznamenaných datových oprav docela pěkné "mapy" rizikových oblastí na nízké oběžné dráze Země. Mimochodem, celou tu stránku můžu jen doporučit, člověk se dozví další zajímavé informace o palubním hardwaru NASA, a je tam i dokumentace a příručky k programovacímu jazyku HAL/S, ve kterém NASA raketoplánový hardware programuje.
(BTW, americké letectvo používalo v některých stíhačkách stejnou architekturu - System/4Pi (pěkná slovní hříčka na System/360, ze kterého jsou odvozeny ;-)) - ale myslím, že jiný jazyk, snad JOVIAL.)
-
Pavel TišnovskýZlatý podporovatelDíky za odkazy. Ten jazyk se fakt jmenuje HAL/S? To by mě zajímalo, jestli se tím inspiroval Clark nebo naopak. No u Clarka ta AI moc dobře neobstála :-)
-
Rejpal (neregistrovaný)Citace z Wikipedie:
HAL is not an acronym. On the Preface page of the HAL/S Specification[1], it says,
Takže moc skynetoidních a HAL9000oidních konspirací bych za tím neviděl. ;-)"....Intermetrics wishes to acknowledge the fundamental contribution to the concept .....made by Dr. J. Halcombe Laning of the MIT's Draper Laboratory."
