ECC-RAM testen

[NOTAUS]

Schaue doch mal bei deinem zukünftigem DDR5- Board nach Hinweisen/Möglichkeiten betreffend ECC. Da sollte es ja im Bios ein paar Einstellmöglichkeiten geben.

 

[CoMo]

Hier gibt es ja sogar einen Screenshot, der die Free Edition zeigt

Also reicht das für meine Zwecke? Ich war irritiert durch diese "ECC Injection", die es nur in der kostenpflichtigen Variante gibt, aber das ist dann irgendwas total advanced, was ich nicht brauche?

 

[SJAFNWEIF]

Ich war irritiert durch diese "ECC Injection", die es nur in der kostenpflichtigen Variante gibt, aber das ist dann irgendwas total advanced, was ich nicht brauche?

Damit werden Fehler provoziert um zu überprüfen, ob ECC ordnungsgemäß funktioniert. Allerdings muss das auch von der Plattform/Chipset unterstützt werden.

 

[nutrix]

Ich möchte testen, ob die Fehlerkorrektur funktioniert; nicht nur, ob sie aktiv ist. Ist das überhaupt möglich und wenn ja, kann ich das auch machen, ohne Geld auszugeben?

Es wird so viel Geld für alles ausgegeben, warum nicht auch für Software, die einen wichtigen Zweck erfüllt? 50 € für so ein Programm ist jetzt auch nicht viel.

 

[NOTAUS]

"Für Multi-Bit ECC muss es der RAM können (+ extra Chip), der Speicher-Controller sowie das UEFI und das Betriebssystem"

 

[CoMo]

Es wird so viel Geld für alles ausgegeben, warum nicht auch für Software, die einen wichtigen Zweck erfüllt? 50 € für so ein Programm ist jetzt auch nicht viel.

Ja ist richtig. Aber wenns nicht nötig ist, kann man sich das Geld ja auch sparen. Und nun scheint sich ja rausgestellt zu haben, dass ich das gar nicht brauche. Um so besser.

"Für Multi-Bit ECC muss es der RAM können (+ extra Chip), der Speicher-Controller sowie das UEFI und das Betriebssystem"

Der RAM ist echter ECC-RAM, beim Board steht in der Beschreibung "Detects double-bit errors (using ECC memory)" und das OS ist Debian 12. Also wirds wohl passen

 

[Drewkev]

und das OS ist Debian 12. Also wirds wohl passen

Solltest du mit dmidecode -t memory herausfinden können.

 

[Donnidonis]

Der ECC RAM ist erstaunlich günstig geworden ...

Das liegt hier daran, dass es RDIMMs sind. Dafür benötigst ein Prozessor + Board, das ordentlich Aufpreis kostet. Das muss unbedingt geprüft werden, ob es unterstützt wird.

 

[0x7c9aa894]

@Donnidonis schon klar, ich habe noch so grob in Erinnerung was ich vor 2 1/2 Jahren für meinen Server Speicher bezahlt habe..

@NOTAUS Multi bit ECC ist mega schlecht dokumentiert. Bei meiner HW stand nichts davon, weder MB noch RAM. Aber wenn der Speicher installiert ist, sind die Tools alle happy, und sagen Multibit ECC wird unterstützt... Scheint mehr Try and Error zu sein.

Ergänzung (29. August 2023)

@Drewkev dmidecode find es heraus. z.B.:

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.

Handle 0x0028, DMI type 16, 23 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: Multi-bit ECC
    Maximum Capacity: 4 TB
    Error Information Handle: 0x0027
    Number Of Devices: 8

 

[Skysnake]

Oft kann man im BIOS das ECC abschalten.
Wenn nicht. Normal werden ECC-Fehler im BIOS-Log Protokolliert

Wenn es denn funktioniert... mache damit nem Hersteller schon Monate Rum, weils nicht tut...

Ehrlich gesagt hab ich in all den Jahren noch nie den RAM vorab getestet und ich kenne auch keinen, der das so macht. Etwas Vertrauen spart Zeit und Geld.

Bei Clustern Standard. Wir haben dafür immer Linpack und Stream genutzt. Das lief für einige Stunden bis nen Tag.

Dazu dann halt das Logging von ECC errors 0ber Ras deamon oder mcelog bzw halt das SEL.

Die Probleme haben mit DDR4 angefangen, weil die Hersteller nicht mehr jeden ECC error loggen sondern z.b. nur jeden 10ten im SEL und das auch nur wenn die schnell genug passieren. Hatte da schon den Fall das es mehr geloggte UECC Fehler gab als ECC Fehler...

Mit DDR5 ist es noch schlimmer geworden. Da werden teils gar keine ECC Fehler mehr geloggt und selbst UECC fehlen im SEL...

Ach so und PostPackageRepair ist meiner Meinung nach auch die Seuche...

Die Ram Hersteller wollen einfach keine Dimms mehr tauschen...

Also reicht das für meine Zwecke? Ich war irritiert durch diese "ECC Injection", die es nur in der kostenpflichtigen Variante gibt, aber das ist dann irgendwas total advanced, was ich nicht brauche?

Mit ECC injection kannst du halt gezielt testen ob das Logging usw tut.

ABET VORSICHT! Das ersistent Post package Repair musst du vorher abschalten sonst haste am Ende nen kaputten RAM....

Schöne neuekomplexe Welt

 

[NOTAUS]

Meinste nicht, dass für deine Zwecke ein ausführlicher (Free-) Memtest reicht? Was nützt die Pro- Version? Nix... Du wirst ohnehin immer mal wieder in die "Fehler-" Logs schauen müssen...

 

[kleiner_muck]

Nur als Anmerkung: bei DDR5 muss man mit den Begrifflichkeiten aufpassen.

Ab DDR5 wird fast immer mit "on-die ECC" geworben. Nach dem wie ich es verstanden habe, korrigiert dieser Fehler lediglich innerhalb der einzelnen RAM-Chips. Es gibt keine Signalisierung an den PC, dass ein Fehler aufgetreten ist. Dies wird wohl genutzt, um die Ausbeute an Chips zu erhöhen, und ist in gewisser Weise eine Mogelpackung.

Im Gegensatz dazu gibt es bei DDR5 weiterhin auch den normalen ECC-Speicher (kombiniert mit "on-die ECC"), wo Einzelbit oder Mehrbit Fehler über mehrere RAM-Chips und den RAM-BUS hinweg erkannt, korrigiert und beim Betriebssystem gemeldet werden können.

 

[Skysnake]

Die Betonung liegt auf können.

In den Bios setting Pumps findet man dann teils so nette Sachen wie: Reporte nur jeden hundertsten Fehler...

 

[h00bi]

Ach so und PostPackageRepair ist meiner Meinung nach auch die Seuche...

Die Ram Hersteller wollen einfach keine Dimms mehr tauschen...

Bei Preisen von 50-60€ nettoür ein 32GB ECC Reg und knapper Marge lohnt es sich halt auch kaum das Ding hin und her zu schicken. Zudem hast du mit hPPR weniger Downtime als wenn du die Kiste öffnen müsstest um das Modul zu tauschen.

Wenn doch spare area vorhanden ist, warum nicht nutzen? Bei Massenspeicher ist das völlig akzeptiert.

Dies wird wohl genutzt, um die Ausbeute an Chips zu erhöhen, und ist in gewisser Weise eine Mogelpackung.

Das ist bei immer weiter steigenden Taktraten bei niedrigerer Spannung einfach unerlässlich geworden.
Auch hier der Verweis auf Massenspeicher: TLC SSDs wären ohne ECC Mechanismen völlig unbrauchbar.

 

[Skysnake]

Bei Preisen von 50-60€ nettoür ein 32GB ECC Reg und knapper Marge lohnt es sich halt auch kaum das Ding hin und her zu schicken. Zudem hast du mit hPPR weniger Downtime als wenn du die Kiste öffnen müsstest um das Modul zu tauschen.

Wenn doch spare area vorhanden ist, warum nicht nutzen? Bei Massenspeicher ist das völlig akzeptiert.

Du musst aber trotzdem rebooten und mit denen eben Diskutieren wenn der PPR eben nichts hilft weil eben ein systematisches Problem mit dem Briegel, der CPU oder dem Board.

Zudem setzen die die Schwelle gerne recht hoch. Die wollen ja nicht das zu viel repariert wird.

Und mich käst das schon an wenn ich 1MB weniger RAM habe. Vor allem wo da die Grenze ziehen?

 

[h00bi]

hPPR - zumindest bei Samsung DRAM - grenzt den Defekten Bereich nicht nur aus sondern ersetzt ihn durch Spare Area, Du hast hinterher identisch viel RAM zu vorher.
Wie das bei anderen RAM Herstellern aussieht weiß ich nicht.

Ich würde an deiner Stelle die Wahl des RAM Herstellers und

und mit denen eben Diskutieren wenn der PPR eben nichts hilft

die Wahl eures Lieferanten überdenken.

 

[Skysnake]

Ich würde an deiner Stelle die Wahl des RAM Herstellers und

Spezifizierst du den RAM Herateller? Zumal PPR bei allen Heratellern meines Wissensnacht geht. Das deckt aber eben NICHT alle Fehlerklassen ab!

Ersistent PPR ist im Vergleich zu Ausblenden von Pages über mcelog nur dahingehend ein Vorteil das es eben wieder 100% Ram ergibt und nach dem Reboot die Pages weiterhin ausblendet. Insbesondere bei Pages die UECC generieren ist das ein Vorteil. Das wars dann aber auch bei Intel. Bei AMD ist es ein größerer Vorteil da das mcelog dort nicht tut und RASDeamon das Ausblenden nicht kann.

Es hilft aber eben nichts gegen Probleme mit dem Channel oder dem RAM Controller in der CPU. Da kommt man dann nämlich nicht über die Schwellwerte für PPR sieht aber trotzdem Perf Probleme. Mcelog hilft da btw auch nicht

die Wahl eures Lieferanten überdenken.

Das Problem hast du bei jedem Hersteller. Keiner täuscht die einfach den RAM seit es PPR gibt. Die RAM Hersteller haben nämlich auch ne ganz andere Vorstellung davon was ein "defekter" RAM Riegel ist und was nicht.

In meinem Bereich ist man da schon sehr picky. Da willst du <1 Fehler pro 24h.

Sprich wenn da übers mcelog mehrere Pages ausgeblendet werden, dann soll der getauscht werden.

PS: ich hatte schon mit ca 10 OEM/ODMs direkt zu tun und ich kann dir sagen das nimmt sich alles nichts. Meine Erfahrung fußt so auf inzwischen wohl >20.000 nodes. Mit wohl so >50.000 node years. Das reicht für etwas Statistik. Man hat also nicht mehr Einzelfälle wo man Glück/Pech hat. Ist wahrscheinlich auch mehr als ein Großteil der Leute in ihrem Leben zwischen die Finger bekommen. Bei mir waren das jetzt keine 10 Jahre.

 

[C4rp3di3m]

Herjee, also ich kann dir für einen Test meine Pro leihen, wenn Du noch brauchst.
Verstehe nur nicht ganz, wenn man so viel Geld für ein Server hat und dann die paar Taler sparen will.

Falls Du brauchst schreibe mich per PN an.

 

[Bohnenhans]

Denke die meisten BIOSe haben ja eine Funktion indem man die SMBios Events oder so nachsehen kann, da werden zumindest auf den ECC Boards die ich habe ECC Fehler eingetragen.

Lässt man also einen ganz normalen MemTest duchlaufen und schaut dann da nach werden korrigierte ECC Fehler dort gezeigt meist sogar welcher Riegel defekt ist, auch wenn das MemTest Tool die nicht meldet, weil es die einfach nicht mitbekommt. Hehe ich habe "zum Glück" einen ECC Riegel ind er Schublade der zuverlässig 1 Bit Fehler produziert so dass ich das testen kann.

Bei mir sieht das dann z.B. so aus, SMBios ist glaube ich eine Standard-Schnittstelle in der ECC immer mitprotoklliert wird wenn SMBios implementiert ist.