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.
Mw E. schrieb: > Aber mit DDR5 wird sich das wohl ändern. > Dieser hat immer integriertes ECC. Laut golem allerdings optional. Siehe Tabelle: https://www.golem.de/news/arbeitsspeicher-ddr5-spezifikationen-sind-final-2007-149658.html
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.
Mein privater Minirechner (STM32H753) hat ECC SRAM!
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.
:
Bearbeitet durch User
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
Jim M. schrieb: > ECC hat Intel erfolgreich aus dem privaten Umfeld verbannt, denn deren > Desktop CPUs unterstützen seit ~10 Jahren kein ECC mehr. Blödsinn: https://geizhals.de/?cat=cpu1151&xf=12099_Desktop+(Mainstream)%7E5_ECC-Unterst%FCtzung%7E820_1150 https://geizhals.de/?cat=cpu1151&xf=12099_Desktop+(Mainstream)%7E5_ECC-Unterst%FCtzung%7E820_1151 https://geizhals.de/?cat=cpu1151&xf=12099_Desktop+(Mainstream)%7E5_ECC-Unterst%FCtzung%7E820_1151+v2
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.