On Sat, 10 Dec 2011, januszek wrote:

> Gotfryd Smolik news napisa?(a):
>
>> Wtedy ma sens obstawienie wszystkiego co można za pomocą ECC i tak
>> dalej, co pozwala utrzymać na chodzie (albo o ile oprogramowanie
>> pozwala: wymigrować obsługą na inny komputer) dany serwer mimo
>> uszkodzenia modułu pamięci czy któregoś kontrolera IO.
>
> ECC nie zabezpiecza przed uszkodzeniem modułu pamięci

Tylko "słabe" ECC, czyli mające redundancję *niższą* niż potrzebna
na wykrycie *i* skorygowanie każdego z bitów jednego modułu
rzeczywiście nie zabezpiecza - z czego nie wynika teza odwrotna,
że się nie da.

> tylko zapewnia
> większą stabilność pracy niż systemy w których używa sie zwykłych
> pamięci (nie ECC czyli bez korekcji).
> ECC zabezpiecza przed efektami przekłamań, które mogą wystąpić
> na skutek rożnych przyczyn od mikro pęknięć i innych defektów
> w strukturze krzemu po promieniowanie kosmiczne, które w postaci
> szczątkowej dociera na Ziemie.

I czym niby jedno przekłamanie różni się z p. widzenia pracy
komputera od drugiego czy owego od padu modułu, umiesz wyjaśnić?
Tym, że raz masz skorygowane pojedyncze słowo (z uwagą niżej)
a przy "padzie" wszystkie? No to raz jeszcze: a co za
różnica?

I bynajmniej *nie* pisałem o celowym uruchamianiu komputera
z zepsutym modułem - lecz padem (w tym "kompletnym") w trakcie
pracy.
Oczywiście zadaniem systemu operacyjnego jest wymigrowanie
wszystkich obszarów, które znalazły się na liście stron uszkodzonych,
w inne miejsca pamięci fizycznej, bo uparte korzystanie z uszkodzonej
pamięci "bo nadmiarowości nam na styk wystarcza" rzecz jasna nie
jest dobrym pomysłem - ale to już krok dalej.

pzdr, Gotfryd