ECC- und non-ECC-Speicher-Riegel unterscheiden sich doch nicht in ihrem Funktionsumfang. Es ist keine ECC-spezifische Logik eingebaut.
Hat ein non-ECC-Speicher-Riegel 8 GB Kapazität und 64 Bit Busbreite, so hat die ECC-Variante 9 GB Kapazität bei 72 Bit Busbreite. Wo die ECC-Information gespeichert ist, ist dem Speicher egal.
Nun kann man auch non-ECC-Speicher mittels IBECC ECC-fähig machen. Wenn man ECC nicht benötigt, könnte man fault injection dazu missbrauchen ECC-Speicher zu non-ECC-Speicher umzufunktionieren, aber mit mehr Speicherplatz.
Da macht es doch wenig Sinn zwischen beiden Varianten zu unterscheiden? Man könnte doch einfach eine Variante anbieten und selektives ECC erlauben. Dann könnte man Kontrollflüsse schützen, während z. B. Video-Streaming-Daten ungeschützt mit höherer Effizienz und geringerer Latenz verarbeitet werden.
Intel könnte dann die ECC-Funktionalität als nachträglich zubuchbares Premium-Feature per Abo-Modell anbieten. Warum hat man sich eigentlich nicht für diese Variante entschieden?
Mir hat mal ein Lieferant versucht zu erklären, dass systematische Einzelbitfehler bei neuen ECC-Riegeln kein Defekt seien, "weil sie ja korrigiert würden".
Mit leicht fehlerhaften Speichern kann man besonders viel Ärger haben. Deswegen wurde ja das Prüfbit erfunden, um solche üblen Fehler möglichst früh zu erkennen. Dem Verkäufer hätte ich Beine gemacht. Der verkauft bestimmt auch einen Sack Vogelfutter zu jeder Kuckucksuhr?
Viele Server protokollieren Bitfehler als Teil von deren Hardware-Management. Genau da Speicher mit höherer Fehlerrate einzusetzen, würde unangenehm auffallen.
Schlimmer noch! Solche Manchmal-Fehler sind nicht einfach zu finden und können jede Software an einer anderen Stelle treffen. Wenn bloß auf dem Bildschirm ein Bildpunkt fehlt, wäre es harmlos. Wenn jedoch bei der Gehaltsabrechnung ein Bit falsch ist, bekommen 1000 Leute kein Geld. Ähnlichen Fall kenne ich.
Schlimmer noch! Solche Manchmal-Fehler sind nicht einfach zu finden und
können jede Software an einer anderen Stelle treffen.
Bei ECC-korrigierten Fehlern merkt die Software exakt gar nichts davon, Du wirst bloss die genannten Log-Einträge und/oder eine blinkende Fault-LED vorfinden.
ECC Speicher ist nicht zur korrektion von Hardwareschrott da sondern um Bitfehler durch Neutrinos auszumerzen. Ist beim PC nicht so relevant, beim Server der Wochenlang läuft aber eher selten neu bootet kann das ganz andere Folgen auf die Programme und das Betriebssystem haben.
Bei ECC-korrigierten Fehlern merkt die Software exakt gar nichts davon,
Du wirst bloss die genannten Log-Einträge und/oder eine blinkende
Fault-LED vorfinden.
Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung veröffentlicht.
Die Bitfehler gibt es aber nunmal im Speicher. Ich setzte nach vielen Defekten Dateien nach dem Kopieren nun schon seit vielen Jahren nur noch Server und Workstations mit ECC ein.
Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
waren solche Ereignisse alle paar Monate "normal".
So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.
Immerhin wurde die Ereignisrate ueber die Jahre dann immer duenner.
Bei Windows bin ich mir da nicht so sicher.
Ein Mainboard, dass eigentlich per Spezifikation auf unbuffered
ECC-RAM bestand, war auch mit unbuffered Non-ECC zufrieden.
Da man gekippte Bits nicht sieht, fiel das auch ueber einige Jahre
nicht negativ auf. :)
Immerhin schonte das den Geldspeicher spuerbar.
Die Bitfehler gibt es aber nunmal im Speicher. Ich setzte nach vielen
Defekten Dateien nach dem Kopieren nun schon seit vielen Jahren nur noch
Server und Workstations mit ECC ein.
Nun ja. Komischerweise haben ja Archive (RAR,ZIP,etc.) Checksummen.
Das da mal etwas kaputt ist, passiert hier vllt alle 10 Jahre einmal.
Und dabei ist noch nicht mal sicher, dass das Archiv bei mir
kaputt gegangen ist, und nicht vorher schon kaputt war.
Z.B. der (Linux-)Labview-Download der c't ist so ein seltener Fall.
Der ist leider offline, und so nicht mehr verifizierbar.
Falls ihn jemand archiviert hat, koennte er ja mal gucken. :)
Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
F.U.D. halten.
Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
waren solche Ereignisse alle paar Monate "normal".
Aber auch nur, wenn man RAMsch eingebaut hat. Sonst hat man solche Ereignisse /nie/ gehabt.
So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.
Bluescreen, unter Windows? Hab ich schon sehr lange keinen mehr gesehen, und die, die ich in den letzten Jahren sah, hatten nichts mit dem RAM zu tun - da ich in meinen Rechnern (und denen im Büro) keinen RAMsch verbaue.
Wer grindigen Billigspeicher von 3rd-Party-Assemblierern wie MDT, Adata, Geil & Co. verbaut, wem RGB-beleuchtete "Gamer"-Module wichtig sind, der wird andere Erfahrungen machen.
Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
waren solche Ereignisse alle paar Monate "normal".
Aber auch nur, wenn man RAMsch eingebaut hat. Sonst hat man solche
Ereignisse /nie/ gehabt.
So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.
Bluescreen, unter Windows? Hab ich schon sehr lange keinen mehr gesehen,
und die, die ich in den letzten Jahren sah, hatten nichts mit dem RAM zu
tun - da ich in meinen Rechnern (und denen im Büro) keinen RAMsch
verbaue.
Wer grindigen Billigspeicher von 3rd-Party-Assemblierern wie MDT, Adata,
Geil & Co. verbaut, wem RGB-beleuchtete "Gamer"-Module wichtig sind, der
wird andere Erfahrungen machen.
Speicherriegelchen kaufte man damals bei A.Z. Elektronik.
Die "Typenangabe" war die Groesse des Riegels.
Immerhin war die Haelfte des RAMs, aus einer groesseren Menge
des guten Siemens RAMs aus Einzel ICs zusammengesteckt.
Wahrscheinlich kennst du sowas aus deinem Kuhdorf gar nicht.
Pech hatte hingegen ein Kollege, der sich etwas besonders gutes
tun wollte. Dessen RAM brauchte fuer den tollen Speed wohl einige
Zehntel Volt mehr, die sein Mainboard nicht liefern wollte.
Was du in deinem Abakus verbaust, ist mir im uebrigen voellig egal.
Speicherriegelchen kaufte man damals bei A.Z. Elektronik.
Du meinst den Ramschladen in der Stresemannstraße?
Die "Typenangabe" war die Groesse des Riegels.
Immerhin war die Haelfte des RAMs, aus einer groesseren Menge
des guten Siemens RAMs aus Einzel ICs zusammengesteckt.
RAMsch. Sag' ich ja.
Wahrscheinlich kennst du sowas aus deinem Kuhdorf gar nicht.
Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung
veröffentlicht.
Per Email? Oder meinst Du eher SNMP?
Oh, ja, ich meinte SNMP, danke für den Hinweis.
So absurd ist SMTP keineswegs. Schon lange sind in als Server gebauten Systemen kleine unabhängig arbeitende Management-Systeme drin, ganz früher optional aber heute obligatorisch, die auftretende Hardware-Ereignisse melden. Und das auch per Mail können, oft mit eigenem Netzwerkinterface.
Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
F.U.D. halten.
Es gibt sie durchaus. Wer etliche Server mit ECC-RAM im Haus hat, kriegt mit den Jahren schon einige Fehler zusammen. Die melden sich ja, werden also nicht übersehen.
Ist aber nicht sonderlich häufig. Ausser bei einer Batterie gleichzeitig beschaffter Server, bei der kurz nach Ablauf der 5 Jahre Wartung bei einem nach dem anderen die RAM Module einem Rappel kriegten.
Und genau da sind wir beim Punkt: Korrektur einzelner Bitfehler ist nützlich, aber die Erkennung ist wichtiger. Wenn man nicht gerade auf Umlaufbahn ist. Besser, die Kiste bleibt stehen, als dass sie die Daten allmählich unterminiert. Gutes Management schaltet ggf das betreffende Modul ab, wenn zu mies, und startet die Kiste mit reduziertem RAM neu.
Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne RAM-Chips komplett die Grätsche machen können, ohne dass die Daten flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also gewissermassen RAID 1 im RAM.
Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
F.U.D. halten.
Es gibt sie durchaus. Wer etliche Server mit ECC-RAM im Haus hat, kriegt
mit den Jahren schon einige Fehler zusammen. Die melden sich ja, werden
also nicht übersehen.
Ist aber nicht sonderlich häufig. Ausser bei einer Batterie gleichzeitig
beschaffter Server, bei der kurz nach Ablauf der 5 Jahre Wartung bei
einem nach dem anderen die RAM Module einem Rappel kriegten.
Und genau da sind wir beim Punkt: Korrektur einzelner Bitfehler ist
nützlich, aber die Erkennung ist wichtiger. Wenn man nicht gerade auf
Umlaufbahn ist. Besser, die Kiste bleibt stehen, als dass sie die Daten
allmählich unterminiert. Gutes Management schaltet ggf das betreffende
Modul ab, wenn zu mies, und startet die Kiste mit reduziertem RAM neu.
Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne
RAM-Chips komplett die Grätsche machen können, ohne dass die Daten
flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also
gewissermassen RAID 1 im RAM.
Meine Erfahrungen habe ich da aus der Anfangszeit, als die SIPPs
noch Parity hatten. Fehler fuehrten da zu einer Meldung des BIOS
verbunden mit einem Neustart. Das wurde ueber die Zeit aber immer
seltener. Vermutlich war im RAM irgendwo ein Nuklid verbaut, dass
nach einiger Zeit keine Neutronen mehr fuer mich uebrig hatte.
Das war auch nicht uebermaessig haeufig, als das man daraus ein
Problem haette konstruieren koennen.
Die Pruefsummen von Archiven aus der Zeit stimmen alle, also kann
es so schlimm nicht gewesen sein. Vom Fall, dass ein Einzelbitfehler
mitarchiviert wurde, vllt abgesehen. :)
Wann ich in meinem Serverchen, der natuerlich ECC hat, nachgeguckt
habe, weiss ich gar nicht mehr.
Vermutlich sind die Hersteller von RAMs auch mittlerweile sensibler
fuer das Problem, und verwenden "strahlende" Komponenten nicht mehr.
P.S.
Das Board danach hatte auch noch Parity. Bei dem sind mir Bit-Fehler
ueberhaupt nicht in Erinnerung.
Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne
RAM-Chips komplett die Grätsche machen können, ohne dass die Daten
flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also
gewissermassen RAID 1 im RAM.
P.S.
Einfach spiegeln reicht uebrigens nicht. Fuer ein Quorum braucht
man mindestens 3 Quellen. :)
Egal was Fujutsi dazu sagt, man kann aus 2 gleichgewichteten Quellen
kein Quorum bilden.
Muss man auch nicht. Man muss nur wissen, welche Seite Mist liefert. Bei HDDs ist das deren CRC/ECC. Bei RAM-Mirroring auch. Hilft bei erkennbaren Mehrbitfehlern und bei Totalausfall von Chips.
