ECC vs on die ECC DDR5

Alexander89

Profi
Thread Starter
Mitglied seit
21.12.2020
Beiträge
5
Hallo zusammen,

da ich gerne einen Homeserver mit Alder Lake bauen würde, ist es momentan schwierig ein passendes Mainboard zu finden, welches ECC DDR4 unterstützt. Da DDR5 von Haus aus on-Die ECC mit sich bringt, würde ich gerne fragen, kann man dies als Ersatz für die ECC Funktion von DDR4 Speicher verstehen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Nein, kann man nicht. Es ist nur ein Teil der ECC Funktionalität. Wenn bitflips innerhalb des Speichers passieren, erkennt on-die-ECC diese - wenn diese aber z.B. auf dem Weg von der CPU zum RAM auftreten, brauch man echtes ECC. Das erkennt dann auch die im RAM. on-die-ECC ist besser als nichts, aber naja.... nichts halbes und nichts ganzes.
 
Supermicro X13SAE-F wäre problemlos verfügbar, mit IPMI und 2.5GBase-T eine runde Sache als Server.

cu
 
wenn diese aber z.B. auf dem Weg von der CPU zum RAM auftreten, brauch man echtes ECC.
Nein, denn schon DDR4 wurde mit einer CRC zur Absicherung vor Übertragungsfehlern versehen und auch wenn damit Übertragungsfehler nur erkannt werden können, so werden die Daten zur Fehlerkorrektur dann erneut übertragen. DDR5 deckt mit der On-Die-ECC nun also auch den kompletten Weg ab, von gekippten Bits im RAM bis zur Übertragung zum RAM Controller.

Man muss aber beachten, dass es bei allem was Sicherheit angeht, keine 100% gibt und wenn es mehr als nichts ist, dann gibt es immer Abstufungen in Richtung der angestrebten 100%. Die On-Die-ECC hat meines Wissens nach 8 Bit ECC pro 128Bit Daten, also über doppelt so viele wie bei DDR4 mit 8 Bit pro 64 Bit üblich war (mit DDR5 sind es wegen der Subchannels ja nun 8 Bit ECC pro 32 Bit Daten). Dabei ist zu beachten, dass eine ECC umso besser funktioniert, je größer beide Zahlen werden, also 16 Bit ECC über 128 Bit sind besser als 8 Bit über 64 Bit, obwohl das Verhältnis gleich bleibt und dies hätte man ja bei DDR4 mit Dual Channel.

Neben der schwächeren ECC fehlt dem On-Die-ECC dann meines Wissens nach (wer da bessere Informationen hat, her damit, man kann ja immerhin bei vielen Modulen auch den Temperatursensor auslesen, vielleicht gibt es ja auch was für RAM Fehler) auch die Überwachung, man erfährt also nicht wie viele RAM Fehler aufgetreten sind und korrigiert wurden und kann auch nicht erfahren und reagieren, wenn ein unkorrigierbarer RAM Fehler aufgetreten ist.

Man kommt also mit der On-Die-ECC den 100% nicht so nahe wie mit normalen ECC RAM, welches ja i.d.R. bei den Intel CPU des Mainstream Sockelns auch nur einfache Bitfehler korrigieren und mehrfache erkennen kann. Die Xeons für den großen Sockel können mehr und wer mal nach Advanced ECC googlet und auf Dinge wie Chipkill stößt, der sieht, dass man den Aufwand noch weiter treiben kann. Deshalb muss man sich fragen was man persönlich erreichen möchte und welchen Aufwand man dafür zu Treiben bereit ist.

Eigentlich wollte ich auch einen Xeon und ECC RAM haben, die kleinen Xeons gibt es nicht mehr, dafür kann nun jeder i3 bis i9 ECC RAM unterstützen, aber nur mit dem W680 Chipsatz, allerdings ist das Angebot an solchen Mainboard mehr als mies Geizhals listet gerade 3, wobei das Supermicro X13SAE-F als bulk und retail zweimal vorhanden und das GIGABYTE MW34-SP0 bei keinem Händler als lagernd angegeben ist. Das war noch gar nicht gelistet, also ich vor einem Monat meine Wahl treffen musst und auch passende DDR5 ECC UDIMM waren da noch praktisch nicht verfügbar. Da hat sich erstaunlich viel getan, obwohl Alder Lake ja nun schon seit über einem Jahr auf dem Markt ist.
 
Hallo zusammen,

da ich gerne einen Homeserver mit Alder Lake bauen würde, ist es momentan schwierig ein passendes Mainboard zu finden, welches ECC DDR4 unterstützt. Da DDR5 von Haus aus on-Die ECC mit sich bringt, würde ich gerne fragen, kann man dies als Ersatz für die ECC Funktion von DDR4 Speicher verstehen?

"On die ECC" hat nichts mit "ECC im Server Sinn" zu tun (da es nur innerhalb der SpeicherChips agiert)

DDR5 kann Aufgrund seines Aufbaus und der Speed selbst intern Fehler produzieren, daher MUSS jedes DDR5 Modul "On die ECC" haben
... nen es einfach eine Maßnahme gegen einene Unzulänglichkeit bei DDR5

nicht umsonst gibt es nur 4800 (auf 2 Slots) jedec Udimms ECC


(SK Hynix entwickelt jedoch grad schnellere bis 8000 (aber nicht UDimms sondern spezielle)
 
Zuletzt bearbeitet:
DDR5 kann Aufgrund seines Aufbaus und der Speed selbst intern Fehler produzieren, daher MUSS jedes DDR5 Modul "On die ECC" haben
... nen es einfach eine Maßnahme gegen einene Unzulänglichkeit bei DDR5

Kann DDR4 auch haben und DDR3, der User bekommt es nur nicht mit.
 
Jedes RAM kann intern Fehler "produzieren", wobei Soft Errors oft durch externe Strahlung verursacht werden und ich da nicht sagen würde, dass das RAM den Fehler selbst produziert hat. Sagen wir also lieber das jedes RAM Fehler auf Zellebene haben kann und ohne On-Die-ECC gehen diese auch nach außen, mit On-Die-ECC werden sie schon auf Die Ebene behoben, wenn auch sicher nicht im gleichen Umfang wie bei anderen ECC Technologien, wie schon gesagt ist das alles relativ und man es eher wie die Stufen einer Treppe verstehen. Mit On-Die-ECC ist man also erst auf der ersten Stufe dieser Treppe.

Laut Samsung soll es die Fehlerraten um 1:10^6 verbessern:

DDR5_On-Die-ECC.jpg


Leider seht da nicht auf was sie die Basis bezieht und natürlich besteht auch die Gefahr, dass Hersteller billige RAM Chips verwenden die schon vor sich aus Fehlern haben, die aber eben noch von der On-Die-ECC korrigiert werden können, die dann aber eben keine weiteren Fehler wie z.B. ein zufällig gekipptes Bit mehr korrigieren kann. Man sollte eben nicht nur nach der Optik entscheiden welche RAMs man kauft.

Aber mit DDR5 ist dieser erste Schritt eben dabei und damit gewissermaßen kostenlos, während es mit Kosten und Einschränkungen verbunden ist einen weiteren Schritt auf der Treppe zu machen. Einschränkungen wie eben die geringe Auswahl und schlechte Verfügbarkeit passender Hardware.
der User bekommt es nur nicht mit.
Den Fehler selbst bekommt der User nicht mit, die Konsequenzen aber zuweilen schon. Dies wird sich durch die On-Die-ECC nicht ändern, da man hier wohl auch nicht erfahren kann, wie viele Fehler korrigiert wurden. Der entscheidende Punkt ist also um wie viel die On-Die-ECC die Fehlerrate wirklich vermindert, 100% sind wie gesagt praktisch kaum zu erreichen. Während also mit DDR5 und nur seiner On-Die-ECC eine normale ECC, auch wenn sie nur Singlebit Fehler korrigieren kann, nicht ersetzt, sondern man auf der Trepper mindestens eine Stufe darunter steht, ist die Frage ob einem dies genügt. Diese Frage muss jeder für sich beantworten, denn er muss ja dabei alles andere wie die verfügbare Hardware und ob diese seinen weiteren Ansprüchen gereicht wird sowie die Kosten, ebenfalls mit einbeziehen.
 
Vielleicht ein wenig einfacher und allgemeiner erklärt für DDR5:

- On Die ECC hilft bei Fehlern innerhalb des DRAMs
- RDIMMs helfen Ende zu Ende (alle anderen Komponenten zu DRAM und zurück).

Sehr gut erklärt in Englisch bei Serve The Home:
 
- RDIMMs helfen Ende zu Ende (alle anderen Komponenten zu DRAM und zurück).
Das hat nichts mit RDIMM zu tun. RDIMM ist die Art und Weise wie der Speichercontroller mit den einzelnen Chips spricht. Das ist unabhängig davon ob ECC oder kein ECC zum Einsatz kommt.

Es gibt technisch:
UDIMM ohne ECC
UDIMM mit ECC
(L)RDIMM ohne ECC
(L)RDIMM mit ECC

Dass RDIMMs in aller Regel ECC haben, liegt daran, dass RDIMM primär für Server oder PowerWS gedacht ist und man da ECC verwendet.
Allerdings ist die Ansprache des DRAMs und die ECC-Funktion strickt voneinander zu trennen.
Denn UDIMM mit ECC stehen RDIMMs im Sinne von ECC in nichts nach. (hier ist explizit die erweiterte ECC-Funktion gemeint)
 
Seit DDR4 gibt es standardmäßig eine CRC bei der Übertragung der Daten und auch wenn man damit keine Fehler korrigieren kann, sondern man kann sie nur erkennen und die Übertragung dann wiederholen bis sie fehlerfrei funktioniert hat, Damit ist man also mit DDR5 mit ODECC ebenso von Ende zu Ende geschützt, Übertragungsfehler können aber zu Performanceproblemen in Form von Verzögerungen führen, eben weil Fehler bei der Übertragung halt nur durch Wiederholung "korrigiert" werden können, während solche Fehler bei ECC RAMs im RAM Controller wirklich korrigiert werden können.
 
Seit DDR4 gibt es standardmäßig eine CRC bei der Übertragung der Daten und auch wenn man damit keine Fehler korrigieren kann, sondern man kann sie nur erkennen und die Übertragung dann wiederholen bis sie fehlerfrei funktioniert hat,
In welche Richtung wirkt denn der CRC?
Wie würde so ein System auf einen Fehler reagieren, der bei der Übertragung von Daten aus dem RAM zur CPU/RAM-Controller passiert?
Weiterhin, welche Mechaniken existieren, damit ein CRC-Fehler für den User diagnostizierbar wird?
 
Google die Details doch einfach mal selbst, die Spezifikationen sind ja nicht geheim.
 
OK, hier die Antwort:

CRC gilt nur für den Schreibvorgang, also die Übertragung in den RAM.
Man spricht hier von einem Write CRC. Dementsprechend gibt es auch einen Read CRC, dieser würde in die entgegensetzte Richtung wirken. Da dieser nicht implementiert ist, ist also nur eine Übertragungsrichtung mit einer CRC versehen.

Damit ist es also nicht korrekt, dass die Übertragung mit einer CRC abgesichert sei. Dies gilt nur für eine Richtung. Die Übertragung vom RAM ist nach wie vor ohne eine CRC und damit weiterhin fehlerbehaftet.

Weiterhin macht die JEDEC keine Festlegungen, wie mit einem CRC-Event umgegangen wird. (bis auf den retransmit durch den Controller)
Dementsprechend ist also, gerade bei Consumerboards, davon auszugehen, dass CRC-Events zwar detektiert werden, aber eben nicht für den User ersichtlich. Sein System kann also Probleme haben, nur bekommt er das nicht.

Daher ist DDR5 mit onDieECC, sowie einer unidirektionalen CRC noch immer kein Ersatz für eine vollständige ECC-Implementierung. (unabhängig vom self correct)

Man sollte sich also davon nicht in die Irre führen lassen.

Wer noch mehr lesen will:
Standard JEDEC JESD79-4
Kapitel 4.16.5
 
Ein Mini Workshop ist ja nun weit von einer Spezifikation entfernt, aber auf Seite 9 steht: " For Read, pp CRC & DBI can be supported at the same time"

Es gibt auch eine einfachere Methode an sowas ranszugehen, nämlich indem man mal kurz darüber nachdenkt. Die erste Frage die man sich stellen sollte wäre z.B. was das ganze soll. Zwei möglich Antworten wären, dass es ein Marketinggag ist oder das man wirklich Fehler bei der Übertragung verhindern will, die ja umso wahrscheinlicher werden je schneller diese erfolgt. Bei HDDs hat man damals mit dem Ultra-DMA Modus auch eine CRC32 pro FIS (Paket aus Daten oder Befehlen) eingeführt, eben weil da die Geschwindigkeit höher wurden. Wenn es eine Marketinggag ist, so hat man offenbar den Teil mit dem Marketing vergessen, da ja kaum jemand davon auch nur gehört hat.

Also hat es wohl technische Hintergründe und damit ist die nächste Frage, was da wohl Sinn macht, die Übertragung nur in die eine Richtung zu schützen oder in beide? Da Daten ja ins RAM geschrieben und von dort möglichst wieder genauso gelesen werden sollen wie sie geschrieben wurden, dürfte die Antwort einfach sein. Zumal wenn man bedenkt, wer solche Spezifikationen erstellt, nämlich die JEDEC und wenn man schaut wer die sind und wer deren Mitglieder sind, so dürften da eine Menge Fachleute beteiligt sein die mehr Ahnung haben als jeder einzelne hier im Forum!
 
Zuletzt bearbeitet:
Ein Mini Workshop ist ja nun weit von einer Spezifikation entfernt, aber auf Seite 9 steht: " For Read, pp CRC & DBI can be supported at the same time"

Ich weiß nicht, der von mit genannte JEDEC JESD79-4 Standard liest sich für mich schon sehr stark nach einer Spezifikation.
Wie sieht denn für dich nen Standard? Die Micky Maus?
Beitrag automatisch zusammengeführt:

Zumal wenn man bedenkt, wer solche Spezifikationen erstellt, nämlich die JEDEC und wenn man schaut wer die sind und wer deren Mitglieder sind, so dürften da eine Menge Fachleute beteiligt sein die mehr Ahnung haben als jeder einzelne hier im Forum!
Und wenn man sich mal vor Augen führt, wer die Chefs dieser Fachleute sind, wird einem noch viel mehr klar.

Die JEDEC ist ein Firmenkonsortium, die sich absprechen, wie ihre Welt funktionieren soll.
Die machen keine Grundlagenforschung um die Technik voranzutreiben oder um das neuste Naturgesetz aufzudecken.
Die machen das, weil deren Firmen in erster Linie Geld verdienen wollen.
D.h. die Ansätze/Ursachen für die Standards werden an ganz anderer Stelle generiert.

Es geht auch nicht darum der JEDEC die Kompetenz abzusprechen. Es geht darum, dass hier Sachverhalte angenommen werden, die so gar nicht angedacht sind. Die Leute die das Andenken ist unter anderem die JEDEC.

Und wer dagegen arbeitet ist die Presse. Und so wird onDieECC gerne mal mit "dem" ECC gleichgesetzt.
Und so wird gerne mal ein CRC mit einem ECC gleichgesetzt.

Beides ist falsch. onDieECC brauchste weil die Chips so groß und die Strukturbreiten so klein sind, dass die statistische Relevanz von Fehler existiert. CRC brauchste, weil die Taktraten so groß sind, dass die statistische Relevanz bei der Übertragung von Fehler existiert.

Zurück zum Nachdenken.
Die RAM-Entwickler machen das, weil die absolute Häufigkeit der Probleme mit der Menge an Versuchen steigt. Wir sind heute in deutlich größeren Größenordnungen unterwegs als vor 20 Jahren. Heute haben Heimrechner das, was damals nicht mal Server hatten. Gleichzeitig werden aber die Probleme größer die Fertigungsverfahren/Standards usw. erzeugen.
Und daher muss man Gegenmaßnahmen ergreifen. DDR4/5 selber erfordert keine solche Maßnahmen, sehr wohl aber die Taktraten, Verfahren, Chipgrößen und Mengen. Und CRC ist seit Jahrzehnten die erste Variante, wie man sowas zumindest aufdeckt. Daher ist der Schluss nur logisch.
Das heißt aber nicht, dass CRC irgendwelche Probleme löst, es deckt sie eben nur auf bzw. erlaubt eine automatische Reaktion.

Kurz um, CRC als auch onDieECC ersetzen kein vollständiges ECC. Sie sorgen nur dafür, dass man ein DDR4/5 System so nutzen kann, wie man es mit FPM-RAM vor 30 Jahren auch gemacht hat. Nämlich einfach nur benutzen ohne besondere Anforderungen.
Ohne diese Verfahren würde heute kein Rechner mehr sauber funktionieren, sie sind also Mittel zum Zweck. Und nicht, damit die Stabilität/Robusheit steigt, nein, damit sie nicht weiter absackt, was sie sonst würde.
 
Zuletzt bearbeitet:
Wer trollt hier wen?
Ich schreibe die SPEC und auch das Kapitel dazu und du machst nen völlig unqualifizierten Beitrag dazu...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh