Notiz Jetzt verfügbar: 32 GB DDR4 UDIMM (mit ECC) von Samsung

Jesterfox schrieb:
Vor allem muss man die Checksummen dann auch noch irgendwo speicher, hat also zusätzliche Zugriffe auf den RAM und mehr Speicherverbrauch.
Das auch, aber vor allem müsste man sicherstellen, dass die Daten auch noch im Cache der CPU stehen und nicht schon ins RAM geschrieben und wieder von dort gelesen werden, denn dann können sie schon korrupt sein, bevor die Prüfsumme darüber gebildet wurde!
 
foofoobar schrieb:
Spannend, "moderne" Betriebssysteme haben also eine eingebaute Glaskugel.
Zeig mir doch bitte die Stellen im Linux oder BSD-Kernel dafür.

Das hat nichts mit Glaskugel zu tun, wenn ein Programm abschmiert, dann weiß Linux, dass etwas nicht stimmt. Natürlich weiß Linux das vorher nicht, erst wenn etwas passiert.

Wie oft schmiert dir das gesamte Linux-System wegen defektem RAM ab? Mir noch nie und ich hatte schon defekte non ECC im Rechner. Ist mir erst Monate später aufgefallen, da manche Programme unregelmäßig abschmierten, die sonst einwandfrei liefen und ich im Log mal nachschaute.

Fehlerhafte Programme werden in Linux geschlossen, im Log kann man danach nachschauen welcher Speicherbereich den Fehler verursachte. Linux verwendet den Speicher dann nicht mehr, außer nach einem Reboot, wenn man nicht explizit den Speicher ausgenommen hat.

Und was soll daran schwer sein, den Speicher eines fehlerhaften Programmes zu testen? Linux weiß genau in welchem Speicherbereich das Programm war und kann einfache Prüfungen über den Bereich laufen lassen (siehe Memtest), das sind ja i.d.R. nur wenige MB RAM die gecheckt werden.

Windows macht es sich da einfacher, Bluescreen, Ende.
Ergänzung ()

foofoobar schrieb:
Wie will man ohne ECC feststellen das der RAM kein Problem hatte?

Das geht natürlich nur, wenn der Fehler zum Beispiel zum kompletten Absturz des Prozesses geführt hat.

Einfach nur falsche Werte und der Prozess läuft dennoch, das kann man ohne ECC natürlich nicht erkennen.
 
flappes schrieb:
Linux weiß genau in welchem Speicherbereich das Programm war und kann einfache Prüfungen über den Bereich laufen lassen (siehe Memtest), das sind ja i.d.R. nur wenige MB RAM die gecheckt werden.
Linux weiß aber nicht weshalb das Programm abgeschmiert ist und jedesmal den Speicher zu testen kostet unnötig Performance. Außerdem hilft das nur wenn der Speicher wirklich defekt ist und zuverlässig jedesmal Fehler liefert. Außerdem muss das Programm erst ein mal wegen dem Fehler abschmieren... rein vom Verhältnis her sind die Datenbereiche aber viel größer als die Codebereiche, die Wahrscheinlichkeit das es also nur die Daten betrifft und das Programm nicht abschmiert ist relativ hoch.

PS: auch Windows beendet fehlerhafte Prozesse und wirft nicht sofort einen Bluescreen. Den bekommt man nur wenn Windows sich nicht mehr anders zu helfen weiß, also die Momenten in denen einem Linux einen Kernel-Panic präsentiert.
 
flappes schrieb:
Das hat nichts mit Glaskugel zu tun, wenn ein Programm abschmiert, dann weiß Linux, dass etwas nicht stimmt. Natürlich weiß Linux das vorher nicht, erst wenn etwas passiert.

Wie oft schmiert dir das gesamte Linux-System wegen defektem RAM ab? Mir noch nie und ich hatte schon defekte non ECC im Rechner. Ist mir erst Monate später aufgefallen, da manche Programme unregelmäßig abschmierten, die sonst einwandfrei liefen und ich im Log mal nachschaute.

Was hat ein Hardwaredefekt, z.b. defekter RAM Riegel, mit ECC zu tun?
 
flappes schrieb:
Wie oft schmiert dir das gesamte Linux-System wegen defektem RAM ab? Mir noch nie und ich hatte schon defekte non ECC im Rechner. Ist mir erst Monate später aufgefallen, da manche Programme unregelmäßig abschmierten, die sonst einwandfrei liefen und ich im Log mal

Oh glaub mir mal desto wichtiger desto eher fällt sowas auf... Erst letztes Jahr im Sommer einen Server bei Strato tauschen lassen müssen (eine ganze Nacht hatte ich zukämpfen das ich zumindest meine Backups ziehen konnte...)
 
flappes schrieb:
Fehlerhafte Programme werden in Linux geschlossen, im Log kann man danach nachschauen welcher Speicherbereich den Fehler verursachte. Linux verwendet den Speicher dann nicht mehr, außer nach einem Reboot, wenn man nicht explizit den Speicher ausgenommen hat.

Das ist falsch. Bitte SIGSEGV, SIGBUS, etc. nicht mit ECC-Fehlern verwechseln.
 
  • Gefällt mir
Reaktionen: gaelic
flappes schrieb:
wenn ein Programm abschmiert, dann weiß Linux, dass etwas nicht stimmt.
Eben, nur weiß es nicht was da nicht stimmt, es kann auch einfach ein Bug in der Software sein.
flappes schrieb:
Wie oft schmiert dir das gesamte Linux-System wegen defektem RAM ab? Mir noch nie
Die Wahrscheinlichkeit ist wie bei Windows ja auch gering, dass ausgerechnet bei den Adressen wichtiger Codesegmente oder Daten des Kernels ein RAM Fehler auftritt, denn die belegen von den heute üblichen vielen GB RAM ja nur einen eher kleinen Teil. Viele Leute glauben immer noch, wenn sie RAM Fehler haben, müssten sie auch automatisch viele Bluescreens bekommen und wenn also nicht der Fall ist, hätten sie auch keine RAM Fehler. Dies ist ein Irrtum.
flappes schrieb:
danach nachschauen welcher Speicherbereich den Fehler verursachte. Linux verwendet den Speicher dann nicht mehr
Wo steht das? So eine Funktion wäre mir nicht bekannt. Schau das mal nach und verlinke die Quelle, wenn Du keine findest, dann weißt Du, dass Du da einem Irrtum unterliegst.
flappes schrieb:
außer nach einem Reboot, wenn man nicht explizit den Speicher ausgenommen hat.
Speicherbereich kann man bei Linux und auch bei Windows ausblenden, aber dies passiert nicht automatisch.
flappes schrieb:
Linux weiß genau in welchem Speicherbereich das Programm war und kann einfache Prüfungen über den Bereich laufen lassen
Könnte, wenn man diese Funktion einbauen würde, aber dies würde auch nicht vor Soft-Errors schützen, also spontan gekippten Bits im RAM. RAM Tests können diese kaum finden, weil die Zeit zwischen dem Schreiben und Lesen der Speicherinhalte bei ihnen extrem kurz ist und damit die Wahrscheinlichkeit, dass gerade dann ein Bit spontan kippt. Mit RAM Tests findet man nur Hard-Errors, also wenn ein Defekt vorliegt, ggf. tritt der auch nur wegen der Einstellung (Spannung, Takt, Timmings) auf, aber es sind reproduzierbare Fehler die bei einer bestimmten Konstellation (z.B. abhängig von den Inhalten anderer Speicheradressen) zu Veränderung des RAM Inhaltes führen.

Aber sowas einzubauen würde Performance kosten und es macht auch keinen Sinn, denn wenn man etwas gegen RAM Fehler tun möchte, dann nimmt man sowieso ein System mit ECC RAM Unterstützung und daher werden die Entwickler auch keinen Aufwand betreiben um aufwendige Funktionen zu realisieren, die irgendwie helfen mit RAM Fehlern auf Systemen ohne ECC RAM umzugehen. Es macht keinen Sinn Behelfslösungen zu bauen, wenn es die richtige Lösung dafür schon lange gibt.
 
  • Gefällt mir
Reaktionen: Teralios und gaelic
Ich bin leider nur Mobil unterwegs, aber ich erinnere mich an ein Paper in dem sich jemand die Domain „eicrosoft“ registriert hatte und mal geloggt hat wer darauf zugreift. Es gab dann u.a. auffällig viele Zugriffe von dem Windows Update-Dienst. Warum? Ein Vertipper sicher nicht (mal auf der Tastatur schauen wo e und m liegen, zumal man die URL des Update-Dienstes garnicht selbst konfiguriert). Naheliegender war:

m = 01101101
e = 01100101

Nun wäre schon großer Zufall wenn bei tausenden von Rechnern das selbe Bit kippt, am plausibelsten war die Vermutung des Paper-Authors, dass bei einem DNS-Resolver ein Bit gekippt war.

Mal als kleiner Einwurf zum Thema kippende Bits und deren Auswirkungen.

Nun überlegt euch mal was passieren kann, wenn es dabei um Gesundheitsdaten oder Daten in einem Beweisverfahren geht. Und wenn die Daten im Speicher schon falsch vorliegen kann ich Prüfsummen erstellen wie ich lustig bin, von einer falschen Ausgangslage kann ich berechnen was ich will. Ohne eine weitere vertrauenswürdige Quelle bringt mir der Aufwand nichts.
 
  • Gefällt mir
Reaktionen: Teralios
das ist ja schön und gut und richtig. Aber hier geht es um einen HOME-Server.
wobei ich für meine cloud/proxmox auch ecc nutze, für den fileserver jedoch nicht, da hier eher selten was systemkritisches geschrieben wird.
 
Es muss eben jeder selbst wissen wie wichtig ihm der stabile und fehlerfrei Betrieb welches Rechners ist.
 
Weiß jemand, warum die 32 GB ECC UDIMMs scheinbar allesamt nicht mehr verfügbar sind?

Gerade ist für ein Bastelprojekt ein ASRock Rack X470D4U (20 PCIe 3.0 Lanes für eigene Geräte nutzbar) eingetrudelt und freute mich schon ein wenig auf 3700X und 128 GB RAM, letzteres sieht gerade aufgrund mangelndem Angebots mau aus :-/
 
JBG schrieb:
Weiß jemand, warum die 32 GB ECC UDIMMs scheinbar allesamt nicht mehr verfügbar sind?
Reserviert für Server-Produzenten/Servermarkt (Nebensatz bei Quelle techpowerup) vermutlich mit direkter Verlötung der Chips auf den Boards, da hier die Marge vermutlich größer ist.

Der Markt für IndustriePCs (bzw. Embedded) / SOM , COMexpress ... (kleiner ITX) mit ECC und Xeon D oder Epyc 3xxx/Ryzen ist ziemlich groß. NXPs neuere Arm CPUs QorIQ unterstützen auch ECC und haben ein ähnliches Anwendungsprofil.

PS: Neben den ECC Modulen sind auch die normalen Riegel nicht mehr lieferbar. Da die großen Riegeln auch nicht von anderen Herstellern verfügbar sind, werden diese Speicherchips vermutlich auch direkt für ähnliche SOM Boards/hochintegrierte Boards benutzt.
 
Bin gespannt ob ich dann in mein x99 auch 256 gb rein geben kann oder ein bios update kommt und ich ein upgrade machen kann bzw könnte 4x32gb module wären schon nice
 
Warum nicht? Bis 96GB hab ich schon ausprobiert^^
Ich schätze sobald die Module weiter verfügbar werden, kommt auch der X99-Test.
 
Corsair vermarktet ab sofort 32GB Riegel OHNE ECC : DDR4-2400C16,2666C16,3000C16. "Vengeance-LPX" Hersteller-Shop-Preisstufen 160€,165€,175€.
3 Monaten nach Ankündigung der erste Drittanbieter mit gleicher Größe.

Aber
MichaG schrieb:
Keine Ahnung wie aktuell Samsungs eigene Homepage ist - dort sind die ECC Module immernoch mit dem Status "Sample" versehen !
nicht ECC = Mass Production
ECC = Sample
 
Kleines Update: Die Samsung 32 GB DDR4-2666 ECC UDIMM sind inzwischen zum Testen da und funktionieren auf X470 und X570 mit Vollbestückung bei 1,20 V und selbst @3200 mit lockeren Auto-Timings völlig problemlos.

Habe gerade leider keine Zeit mit Timings herumzuspielen, da viele Baustellen offen sind.
 
  • Gefällt mir
Reaktionen: uli_2112, MichaG, HisN und eine weitere Person
Zurück
Oben