Die Frage bezieht sich auf den Rechner, mit dem ihr privat arbeitet,
spielt oder sonst was macht. Also vor dem ihr davor sitzt und dessen
Bildschirmausgabe an eurem Bildschirm seht.
Es sind damit keine Server und kein NAS gemeint.
Falls ihr die Frage mit einem "ja" beantwortet könnt und ihr auch die
entsprechenden ECC RAM Module eingebaut habt, die CPU das unterstützt
und ECC auch nachweislich funktioniert, würde mich jetzt noch
interessieren, wie oft es bei euch vorkam, dass die Fehlerkorrektur
einen single bit Fehler korrigieren musste und wie oft ihr informiert
wurde, dass ein dual bit Fehler auftrat?
Solche ECC Fehler können glücklicherweise ja in der Regel protokolliert
werden. Was sagen da eure Logs?
Vor etwa 8Jahren habe ich meine letzte Workstation mit ECC-Speicher
entsorgt.
Der Linux-Kernel hat in der Mitte der Lebensdauer des Systems eine
riesige Litanei an ECC-Fehlern ausgespuckt. Dies lag an einem defekten
Speicherriegel, nach einem Tausch gab es keine Fehler mehr.
Es war damals sehr praktisch ECC zu haben, da ich dadurch keinen Ausfall
des Systemes in einer kritischen Projektphase hatte.
Richard schrieb:> Es war damals sehr praktisch ECC zu haben, da ich dadurch keinen Ausfall> des Systemes in einer kritischen Projektphase hatte.
Und wie verhält es sich mit deinem heutigen System in Hinblick auf so
Sachen wie unerwarteter Programmabsturz, seltsames Verhalten usw.?
Früher hatte ich privat auch ECC-Speicher. Wird aber von
08/15-Mainboards mittlerweile nicht mehr unterstützt.
Für den Verein haben wir einen Server in einem Datacenter, da war es
schon sehr praktisch, dass er uns ECC-Fehler vermeldet hat statt gleich
abzustürzen. Den fraglichen Riegel konnten wir daher zu genehmer Zeit
tauschen.
Meine Privatrechner hatten bisher alle keinen ECC RAM.
Aber mit DDR5 wird sich das wohl ändern.
Dieser hat immer integriertes ECC.
Auf dem RAM Die selbst integriert, der CPU Speichercontroller muss das
daher nicht mehr können und weitere Datenleitungen auf dem Mainboard
brauchts auch nicht mehr.
Die Frage ist nur was die Hersteller dann in ihren BIOS/UEFI vermurksen.
Wenn die Meldung des RAMs nicht beim OS ankommt isses ja auch sinnlos.
In meinem Desktop läuft tatsächlich ECC Speicher. AMD sei dank gibt es
ECC ja auch wieder für Normalkunden.
Gekauft habe ich den tatsächlich aber eher wegen des Preises. Der war
damals relativ günstig zu bekommen, da der Markt für die Sorte Speicher
leergekauft wurde (Samsung B-Die, funktionierte mit AMD
Speichercontrollern initial deutlich besser als der Rest). Da die
meisten Endkunden den ECC Speicher allerdings gar nicht im Blick hatten,
war der relativ preisgünstig zu haben. ECC ist da nur ein netter Bonus,
sodass ich den Speicher irgendwann direkt in meinem Homeserver
verfrachten kann.
Auf dem Board hier (ASUS X370-F Strix) funktioniert ECC, aber außerhalb
meiner Übertaktungsversuche habe ich bislang keine Speichermeldungen
gesehen. Allerdings schaue ich da auch nicht direkt nach.
Mw E. schrieb:> Meine Privatrechner hatten bisher alle keinen ECC RAM.>> Aber mit DDR5 wird sich das wohl ändern.> Dieser hat immer integriertes ECC.> Auf dem RAM Die selbst integriert, der CPU Speichercontroller muss das> daher nicht mehr können und weitere Datenleitungen auf dem Mainboard> brauchts auch nicht mehr.
Leider ist das eine halbgare Lösung: Die Übertragung RAM <-> CPU bleibt
da ungesichert.
Im privaten Desktop habe ich kein ECC-RAM; an den letzten
Komplettabsturz, BSOD oder derlei Kleinkatastrophen kann ich mich
trotzdem nicht erinnern.
Im privaten NAS hingegen läuft ECC-RAM, das NAS hat mich aber auch noch
nicht über RAM-Bitfehler informiert... Ich scheine mit meinen
RAM-Riegeln wohl großes Glück gehabt zu haben.
Matthias L. schrieb:> Im privaten Desktop habe ich kein ECC-RAM; an den letzten> Komplettabsturz, BSOD oder derlei Kleinkatastrophen kann ich mich> trotzdem nicht erinnern.
Das muss sich nicht gleich extrem auswirken.
Es reicht ja schon, wenn ein Programm mal abschmiert oder falsch
initialisiert wird und mit Fehlerdaten weiterläuft.
Ebenso KEIN ECC Speicher im Desktop und Laptop. Ich sehe da nur sehr
geringe Risiken durch RAM-Fehler, vergleichen mit dem Rest
(Softwareprobleme, Akku leer, ...).
Im Server hab ich ECC, das war dort Standard. Dort ist mir die
Verfügbarkeit wichtiger weil relativ viele Systeme mit dran hängen
(daher auch USV etc.). Aber auch nach mehr als 300 Tagen Laufzeit hatte
ich aber noch keinen einzigen Fehler in 32GB RAM.
Meno schrieb:> Leider ist das eine halbgare Lösung: Die Übertragung RAM <-> CPU bleibt> da ungesichert.
Kommt drauf an, gegen was du dich alles absichern willst bzw. wie das
Risiko auf dem Übertragungsweg ist. Da sind wir dann nämlich ganz
schnell bei Themen wie: Sichere ich auch Caches in der CPU ab? Oder
sogar Register?
Das ist übrigens gar nicht so absurd wie es klingt. Es gibt Systeme wo
auch die CPU Register per ECC abgesichert sind, selbst schon mit
gearbeitet.
Meno schrieb:> Leider ist das eine halbgare Lösung: Die Übertragung RAM <-> CPU bleibt> da ungesichert.
Den Off die ECC gibts immernoch, also 1 DRAM IC mehr drauf und los
gehts.
An dich wurde also gedacht ;)
Nano schrieb:> Laut golem allerdings optional.
Laut Wiki und Computerbase nicht optional.
Wir werden sehen wenns so weit ist.
Johannes O. schrieb:> Sichere ich auch Caches in der CPU ab?
Bei Caches ist mindestens bei AMD schon sehr lange ECC queerbeet üblich,
nicht nur bei den Server-Prozessoren. Beim Instruction Cache beschränkt
man sich auf Parity, weil diese Daten verworfen werden können. Und schon
der PCI Bus hatte Parity, PCIe hat CRC. Buszyklen werden ggf wiederholt.
Mw E. schrieb:> Nano schrieb:>> Laut golem allerdings optional.> Laut Wiki und Computerbase nicht optional.> Wir werden sehen wenns so weit ist.
Also wenn's nicht optional ist, sondern default, dann wäre mir das nur
recht.
Ich hoffe jetzt nur, das ich in nächster Zeit keinen neuen Rechner
brauche, damit ich den nächsten gleich mit DDR5 kaufen kann.
Nano schrieb:> Es sind damit keine Server und kein NAS gemeint.
Eigentlich ist die Frage gerade bei NAS interessant. Bei der
Grössenklasse fürs Heim scheint das nicht üblich zu sein.
Nano schrieb:> Und wie verhält es sich mit deinem heutigen System in Hinblick auf so> Sachen wie unerwarteter Programmabsturz, seltsames Verhalten usw.?
Ich hatte in der Zwischenzeit nur einen Absturz, welcher auf einen
defekten Riegel zurueckzufuehren war.
Ansonsten gab es keine Ausfaelle.
In meinem NAS, welchen ich mittlerweile als Workstation (Remote Desktop)
verwende (CAD, Spiele) ist ECC verbaut, aber seit etwa 2 Jahren noch
kein Ausfall zu verzeichnen, trotz gebrauchter Serverhardware.
Nano schrieb:> Es sind damit keine Server und kein NAS gemeint.
ECC hat Intel erfolgreich aus dem privaten Umfeld verbannt, denn deren
Desktop CPUs unterstützen seit ~10 Jahren kein ECC mehr. Und die Xenons
laufen auch nicht mehr auf den Desktop Chipsätzen.
Die Ryzen ohne GPU würden ECC unterstützen, aber man bekommt z.B. keine
DDR-3200 Riegel mit ECC AFAIK. Das ist eine Nebenwirkung, denn die kauft
ja keiner für privat.
Zu Beachten wäre auch, das neuere Ryzen (Zen 2 und Zen 3) intern ECC
benutzen und auch intern ECC Fehler produzieren können - insbesondere
bei hohem FCLK. Das ist unabhängig vom RAM ECC und betrifft die
Kommunikation Compute-Die <-> I/O Die.
Es gibt allerdings auch Server Boards mit X570 Chipset, ich müsste aber
erst nachsehen wo ECC Fehler angezeit würden.
(prx) A. K. schrieb:> Nano schrieb:>> Es sind damit keine Server und kein NAS gemeint.>> Eigentlich ist die Frage gerade bei NAS interessant. Bei der> Grössenklasse fürs Heim scheint das nicht üblich zu sein.
Bei einem NAS gehe ich davon aus, dass man ECC nimmt.
Insofern erübrigt sich für mich die Frage da.
Beim Desktop sieht's aber schon anders aus.
Heute Morgen musste ich mein Debian System zweimal booten.
Beim ersten mal gab's irgendein Problem und die genaue Ursache kenne ich
nicht.
Einmal runterfahren und neu hochfahren führte dann wieder zu einem
fehlerfrei funktionierendem System, wie ich es auch gestern und die Tage
zuvor benutzt habe.
Da stellt sich dann einem schon die Frage, ob auch mal ein gekipptes Bit
dafür verantwortlich sein könnte.
Verändert wurde am System jedenfalls nichts.
Ein kaltes System (Leiterbahnen ziehen sich zusammen) wäre noch eine
Erklärung, aber dann wäre der Rechner wohl eher gar nicht gestartet.
Nano schrieb:> Bei einem NAS gehe ich davon aus, dass man ECC nimmt.
Beim Heim-NAS scheint das mitnichten selbstverständlich zu sein, im
Gegenteil. Klar, wer sich das selber zusammenbaut... aber bei Qnap&Co
unterhalb der Profi-Klasse?
Jim M. schrieb:> Nano schrieb:>> Es sind damit keine Server und kein NAS gemeint.>> ECC hat Intel erfolgreich aus dem privaten Umfeld verbannt, denn deren> Desktop CPUs unterstützen seit ~10 Jahren kein ECC mehr.
Stimmt nicht ganz.
In meinem NAS läuft ein Pentium G4500, der kann ECC.
https://ark.intel.com/content/www/de/de/ark/products/90730/intel-pentium-processor-g4500-3m-cache-3-50-ghz.html
Genauso auch wie die Core i3 CPUs.
Man braucht allerdings nen Xeon Chipsatz + Server oder Workstation
Mainboard.
In meinem Fall C236. C232 wäre damals auch gegangen.
Für modernere CPUs dürfte wohl C246 relevant sein, aber der ist auch
schon wieder ein paar Jahre alt, da könnte es also wieder einen neuen
geben.
Im Prinzip sind es somit eigentlich nur die i5 und die i7 CPUs, wo der
ECC Support von Intel deaktiviert ist.
Also im Grunde die CPUs, die den Xeons im Bereich Leistung und Core
Anzahl Konkurrenz machen könnten.
(prx) A. K. schrieb:> Nano schrieb:>> Bei einem NAS gehe ich davon aus, dass man ECC nimmt.>> Beim Heim-NAS scheint das mitnichten selbstverständlich zu sein, im> Gegenteil. Klar, wer sich das selber zusammenbaut... aber bei Qnap&Co> unterhalb der Profi-Klasse?
Ich weiß, Synology und QNAP haben kein ECC RAM und der Rest der
Consumerklasse erst recht nicht, aber Zuhause nutze ich TrueNAS und habe
mir den natürlich passend zusammen gestellt.
Jim M. schrieb:> Die Ryzen ohne GPU würden ECC unterstützen, aber man bekommt z.B. keine> DDR-3200 Riegel mit ECC AFAIK. Das ist eine Nebenwirkung, denn die kauft> ja keiner für privat.
Die DDR4-3200er sind letztendlich auch nur übertaktete Chips. Während
die ECC Riegel einfach mit der formalen Spezifikation ausgeliefert
werden, werden die von den Endkundenherstellern einfach werksübertaktet.
Meine 2133 MHz Samsung ECC Riegel laufen z.B. problemlos auf 3200 MHz.
Wen es interessiert, hier ist ein interessantes Dokument zur Frage, ob
ECC RAM zur Abschwächung von Rowhammerangriffen hilft und ob man trotz
ECC so einen Angriff durchführen kann, was in dem Dokument auch gezeigt
wird:
https://cs.vu.nl/~lcr220/ecc/ecc-rh-paper-sp2019-cr.pdf
Da mir die Zeit fehlt, habe ich es nicht ganz gelesen, sondern nur grob
überblättert, aber einige Abschnitte waren schon interessant.
Nano schrieb:> Da mir die Zeit fehlt, habe ich es nicht ganz gelesen, sondern nur grob> überblättert, aber einige Abschnitte waren schon interessant.
Wer sich beim Kochen, Basteln oder sonst wie Entspannen berieseln
möchte, dann gibt es das auch als Vortrag:
https://media.ccc.de/v/cosin-50-rowhammer_exploit
