ECC (Error Checking & Correction) Hauptspeicher oder RAM

WindHund

Grand Admiral Special
Mitglied seit
30.01.2008
Beiträge
12.187
Renomée
532
Standort
Im wilden Süden (0711)
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2012
  • BOINC Pentathlon 2013
  • BOINC Pentathlon 2014
  • BOINC Pentathlon 2016
  • BOINC Pentathlon 2021
Wenn es um ECC geht, scheiden sich die Geister heute noch, wer braucht es, warum macht man es, wie funktioniert es.
Der Thread soll ein Anfang sein die wichtigsten Grundlagen mal zusammen zu bringen, ich hoffe auf Rege Anteilnahme.

Eine Guten Einstieg findet man z.B. hier: http://drwe.de/aktuelles/warum-ecc-speicher-wichtig-ist/

Grundsätzlich ist es so, dass Fehler immer und überall Auftreten können, je mehr Kapazität, desto öfter der Zugriff desto höher die Fehlerrate.
DDR4 bringt wohl ein paar Techniken mit welche Paritäts Fehler im I/O Bereich abfangen können, dazu gibt es aber noch keine bestätigen Infos.

Studien über Speicher Fehler:
https://www.heise.de/newsticker/mel...l-haeufiger-als-bisher-angenommen-828883.html
https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf

Unter Windows kann man mit dem Befehl in der Kommandozeile die Fehlerhaften Speicherbereiche anzeigen lassen:
Code:
bcdedit /enum {badmemory}
Sollten dann Speicheradressen Auftauchen, besteht ein Hardware Error, so sieht es aus wenn keine Fehler vorliegen: http://abload.de/img/bcdedit_eccuqoea.jpg

Mich würde noch interessieren, ob sich ChipKill bei meinem System aktivieren lässt: http://abload.de/img/ecc_aida64_hwinfo64mbor8.jpg

To be continued...

€dit: 08.04.2017
Links zu weiteren Infos Rund um ECC RAM auf Ryzen Bezogen:
https://www.hardwareluxx.de/communi...l-kein-mainboard-mit-ecc-support-1154800.html
http://www.hardwarecanucks.com/foru...ws/75030-ecc-memory-amds-ryzen-deep-dive.html
 
Zuletzt bearbeitet:
Für ChipKill muss im BIOS das "ECC Symbol Size" auf x8 gesetzt werden (MSR D18F3x180 Bit 25 = 1), außerdem muss "DCT data interleaving" aktiviert sein (MSR D18F2x110 Bit 5 = 1). Ansonsten funktioniert es aber auch wohl nur wenn das "DRAM device" eine "width" von "x4" hat: "DRAM device width refers to the number of bits sourced simultaneously from a single memory chip. For example, a x4 device contributes 4-bits to the ECC word on each beat of data." Siehe BKGD ab Seite 243: http://support.amd.com/TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
 
Ja, RWEverything sollte funktionieren, auch zum Setzen von Werten, wenn es ein R/W-Wert ist.
 
Ja, RWEverything sollte funktionieren, auch zum Setzen von Werten, wenn es ein R/W-Wert ist.
Hab ich versucht, aber nichts heraus lesen können, wie war das nochmal mit Hexadezimal? ;D
Laut SIV64X sind es 2x 4 Speicherbereiche a 4Bit (kalkuliert)

siv64x_chipsetmchh7oi0.jpg


RW-Utility Version 1.6.9: https://abload.de/img/rw-utility_169_spdf6oan.jpg
 
Zuletzt bearbeitet:
Umrechnen zwischen Binary und Hex kann calc.exe in der Programmierer-Einstellung. Aber ich habe mich falsch erinnert: Das ist nicht der MSR, wo die Werte stehen, das ist bei den PCI-Daten. D18F2x110 müsste heißen (Bus 00 nehme ich an?) Device 18 Function 02 und 110 müsste das Offset sein, oder so. Und man muss auf 32 bit umstellen.
 
Zuletzt bearbeitet:
DDR4 bringt nur Techniken mit um Übertragungsfehler zu erkennen, ECC RAM deckt diese mit ab und offenbar sind Übertragungsfehler bei den RAM Takten für die DDR4 spezifiziert ist schon ein echtes Problem, denn die Normen sehen eigentlich immer nur dann einen Schutz vor Fehler vor, wenn dies so oft auftreten könnten, dass die Rechner sonst nicht mehr meistens und bei den meisten User funktionieren. Das war damals bei HDDs nicht anderes, erst mit den Ultra-DMA Übertragungen wurden im Protokoll eine CRC32 für jedes FIS (ein Datenpaket kann bis zu 8192Byte Nutzdaten übertragen) eingeführt, vorher was die Übertragungen langsam und ungeschützt.

Gelegentliche RAM Fehler und in Folge dann korrupte Dateien oder Abstürze muss man bei Consumer HW eben in Kauf nehmen, wer mehr Stabilität und Sicherheit für seine Daten möchte, greift zu HW mit ECC RAM Unterstützung und setzt dort ECC RAMs ein. Das kostet etwas mehr und da Consumer HW vor allem billig sein soll und es reicht wenn sie meistens problemlos läuft, ist ECC RAM solange kein Standard bis man es ohne nicht mehr erreichen kann, dass die HW für die Kunden ausreichend stabil läuft.
 
Umrechnen zwischen Binary und Hex kann calc.exe in der Programmierer-Einstellung. Aber ich habe mich falsch erinnert: Das ist nicht der MSR, wo die Werte stehen, das ist bei den PCI-Daten. D18F2x110 müsste heißen (Bus 00 nehme ich an?) Device 18 Function 02 und 110 müsste das Offset sein, oder so. Und man muss auf 32 bit umstellen.
Super, danke das mit der calc.exe wusste ich sogar, bloß in dem Moment nicht. :)
PCI-Adressen meinst du sicherlich?

DDR4 bringt nur Techniken mit um Übertragungsfehler zu erkennen, ECC RAM deckt diese mit ab und offenbar sind Übertragungsfehler bei den RAM Takten für die DDR4 spezifiziert ist schon ein echtes Problem, denn die Normen sehen eigentlich immer nur dann einen Schutz vor Fehler vor, wenn dies so oft auftreten könnten, dass die Rechner sonst nicht mehr meistens und bei den meisten User funktionieren. Das war damals bei HDDs nicht anderes, erst mit den Ultra-DMA Übertragungen wurden im Protokoll eine CRC32 für jedes FIS (ein Datenpaket kann bis zu 8192Byte Nutzdaten übertragen) eingeführt, vorher was die Übertragungen langsam und ungeschützt.

Gelegentliche RAM Fehler und in Folge dann korrupte Dateien oder Abstürze muss man bei Consumer HW eben in Kauf nehmen, wer mehr Stabilität und Sicherheit für seine Daten möchte, greift zu HW mit ECC RAM Unterstützung und setzt dort ECC RAMs ein. Das kostet etwas mehr und da Consumer HW vor allem billig sein soll und es reicht wenn sie meistens problemlos läuft, ist ECC RAM solange kein Standard bis man es ohne nicht mehr erreichen kann, dass die HW für die Kunden ausreichend stabil läuft.
*great*
Wenn es bald die 64GByte Module gibt, dann sehen wir wie hoch der Takt gehalten werden kann. ;)
Mit Octa-Channel wären das in Summe 0.5TByte RAM...
 
Wenn es bald die 64GByte Module gibt, dann sehen wir wie hoch der Takt gehalten werden kann. ;)
Mit Octa-Channel wären das in Summe 0.5TByte RAM...

Nichts unter Quad-Naples mit 2TB RAM. *buck*
 
Für Systeme mit ZFS-Pools ist ECC-RAM praktisch Pflicht, da dieses Dateisystem das RAM viel exzessiver nutzt als andere FS:
https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/
Zum Glück baut DDR4 auf einfachen ECC, für größere Pools ist Multi-Bit oder "Chip-Kill" ECC zu bevorzugen. ;)

Die Zeiten von Dual-, Trippel- oder Quad-Channel gehören der Vergangenheit an, da jedes Modul direkt an den CPU-Controller angebunden ist und so jedes weitere Modul einen Zuwachs der Transferrate bewirkt. Die Signalqualität ist - trotz Erhöhung der Signale von 240 auf 288 Kontakte - verbessert worden. Die Fehlererkennung und -korrektur wurde ebenfalls gesteigert
Quelle: http://www.hardwareschotte.de/magazin/ddr4-ein-aktueller-ueberblick-a41810

*yeah*
 
Bitte was? Quad-Channel gehört der Vergangenheit an? Was haben die denn geraucht?
 
Zum Glück baut DDR4 auf einfachen ECC, für größere Pools ist Multi-Bit oder "Chip-Kill" ECC zu bevorzugen. ;)


Quelle: http://www.hardwareschotte.de/magazin/ddr4-ein-aktueller-ueberblick-a41810

*yeah*

Den ist aber klar das sich dadurch die Bandbreite durch die Begrenzung des Speicherbusses reduziert.

Alter Hut, wenn man mal bei AMD nach Ganged und Unganged guckt.

1x mit 128 Bit übertragen, gut für Grafik On Chip oder 2x 64 Bit pro Task aber weniger Bandbreite.

Dürfte ja dann bei 4x 64 Bit liegen pro verlöteter Speicherbank und 4 Stück hat man davon.
 
Zum Glück baut DDR4 auf einfachen ECC, für größere Pools ist Multi-Bit oder "Chip-Kill" ECC zu bevorzugen. ;)
Was für ein Blödsinn, aber im Netz kann man eben jede Menge Mist finden. ECC hat auch nichts mit DDR, DDR2, DDR3 oder DDR4 zu tun, die Riegel sind ja alle 64 Bit breit und als ECC Riegel eben 72bit. Das RAM direkt am RAM Controller hängt, war auch schon immer so, selbst als der noch im Chipsatz statt wie heute in der CPU untergebracht war und der alleine bestimmt, wie er diese zusätzlichen Bits nutzt, wo er Daten und Prüfsummen speichert und welche Fehler er damit erkennen und beheben kann.

DDR4 unterscheidet sich von der Sicherheit gegenüber den Vorgängern nur darin, dass die Übertragung nun bei allen DDR4 RAMs vor Fehlern gesichert wird, Das schützt halt vor Übertragungsfehlern, aber eben nicht vor den eigentlichen RAM Fehlern, also wenn ein Bit in einer Zelle kippt, bringt das nichts.
 
Bitte was? Quad-Channel gehört der Vergangenheit an? Was haben die denn geraucht?
Das bezieht sich auf die anzahl der Module nicht auf Quad Channel allgemein.
Man braucht also keine 4 Module mehr um Quad Channel nutzen zu können.
Allerdings benötigt man "stacked RAM" Module.

Den ist aber klar das sich dadurch die Bandbreite durch die Begrenzung des Speicherbusses reduziert.

Alter Hut, wenn man mal bei AMD nach Ganged und Unganged guckt.

1x mit 128 Bit übertragen, gut für Grafik On Chip oder 2x 64 Bit pro Task aber weniger Bandbreite.

Dürfte ja dann bei 4x 64 Bit liegen pro verlöteter Speicherbank und 4 Stück hat man davon.
Die meisten sprechen davon, dass die Speicherzellen noch nicht schnell genug sind, der IMC ist scheinbar nicht das Nadelöhr.
Das sind aber nur Mutmaßungen, da würde ich noch etwas warten bis RYZEN released wurde.

Was für ein Blödsinn, aber im Netz kann man eben jede Menge Mist finden. ECC hat auch nichts mit DDR, DDR2, DDR3 oder DDR4 zu tun, die Riegel sind ja alle 64 Bit breit und als ECC Riegel eben 72bit. Das RAM direkt am RAM Controller hängt, war auch schon immer so, selbst als der noch im Chipsatz statt wie heute in der CPU untergebracht war und der alleine bestimmt, wie er diese zusätzlichen Bits nutzt, wo er Daten und Prüfsummen speichert und welche Fehler er damit erkennen und beheben kann.

DDR4 unterscheidet sich von der Sicherheit gegenüber den Vorgängern nur darin, dass die Übertragung nun bei allen DDR4 RAMs vor Fehlern gesichert wird, Das schützt halt vor Übertragungsfehlern, aber eben nicht vor den eigentlichen RAM Fehlern, also wenn ein Bit in einer Zelle kippt, bringt das nichts.
Naja Blödsinn ist bestimmt dabei, aber es gibt noch nicht genug Infos um sich ein eindeutiges Bild zu machen.
Ein paar weitere Quellen habe ich gefunden:

https://www.semiwiki.com/forum/cont...re-efficient-server-storage-applications.html
At the device (DDR4 DRAM) level, using ECC or CRC techniques is the most efficient approach, even if it’s not the only one. For basic operation, using Hamming Codes allow SECDED protection (Single-Error-Correct, Double-Error-Detect), but for advanced operation you have to use Block-Based Codes for SxCyED protection (x-Error-Correct, y-Error-Detect). Implementing Block-Based codes for DRAM is equivalent to RAID for HDD.

http://www.elektronik-kompendium.de/sites/com/1312291.htm
Bei DDR4 bleibt das Prefetching mit 64 Byte erhalten. Statt dessen verteilt man die Zugriffe auf die internen Speicherbänke geschickter. Im Prinzip ist das auch Prefetching, aber eben auf einer anderen Ebene.

https://en.wikipedia.org/wiki/DDR4_SDRAM
DDR4 SDRAM was released to the public market in Q2 2014, focusing on ECC memory...
In addition, there are three chip select signals (C0, C1, C2), allowing up to eight stacked chips to be placed inside a single DRAM package. These effectively act as three more bank select bits, bringing the total to 7 (128 possible banks).
 
Man braucht also keine 4 Module mehr um Quad Channel nutzen zu können.
Allerdings benötigt man "stacked RAM" Module.
Ja nur was ist Stecked RAM? Eben sehr kompakt untergebrachte Dies:
Die die Reduzierung der Entfernungen kann man auch die Bandbreite der Anbindung erhöhen, aber dies geht eben nicht auf normalen RAM DIMMs, dies ist was man auch als HBM direkt im Gehäuse des Chip kennt. Das hat also mit RYZEN erstmal nichts zu tun, solange AMD keine CPU mit HBM rausbringt.

Naja Blödsinn ist bestimmt dabei, aber es gibt noch nicht genug Infos um sich ein eindeutiges Bild zu machen.
Ein paar weitere Quellen habe ich gefunden
Wo ist der Zusammenhang? Du findest da was, verstehst aber nicht was und wie es zusammen hängt. Ob Hamming oder Block-Based codes verwendet werden, ist alleine eine Sache des RAM Controllers, den RAMs ist das egal, denn wie ich schon geschrieben habe bestimmt alleine der Controller wie er die zusätzlichen 8 Bits nutzt die ein ECC RAM Riegel mit seinen 72 Bit statt den 64 Bit ihm bietet. Letztlich speichert er auch nur 8 Byte an Daten in den 72 Bits ab, bei Dual Channel hat er dann eben 144 Bits zur Verfügung um 16 Byte zu speichern und bei Quad Channel eben 288 Bits über 32 Byte an Nutzdaten. Das Verhältnis bleibt gleich, der RAM Controller hat immer 9 Bit um 8 Bits an Daten zu speichern, aber je größer die Zahlen werden, umso effizienter kann man Fehler finden und korrigieren.

Was Prefetching mit ECC zu tun haben soll, erschließt sich mir nicht so ganz, außer dass man eben die Tatsache nutzen könnte das je nicht immer nur ein Zeile gelesen wird, sondern wegen Prefetching dann z.B. 8 hintereinander, also bei DualChannel 8x16 Byte pro Zugriff und damit die ECC über noch mehr Daten verteile könnte, womit wieder gilt: "je größer die Zahlen werden, umso effizienter kann man Fehler finden und korrigieren." Wo das wie weit implementiert ist, kann ich nicht sagen, ob RYZEN überhaupt ECC RAM unterstützt, ist ja auch noch gar nicht bekannt, aber Naples wird es sicher machen. In jedem Fall hat man aber bei DDR4 die CRC zu Sicherung der Übertragung, nur schützt diese eben nicht vor Fehlern durch in den Zellen gekippte Bits.

Das ganze Prefetching kommt daher, dass RAMs sehr langsam im Vergleich zu CPUs sind und damit meine ich vor allem die Latenz, also die Zeit die es dauert von der Adressierung bis die Daten da sind. Da meistens mehrere aufeinander folgende Daten benötigt werden, holt man dann eben über Prefetching nicht nur die angeforderten Daten, sondern gleich noch die nachfolgenden in den Cache. Das wären eben z.B. bei Dual Channel und 8 fach Prefetching eben 8x16Byte, also 128Byte (oder 64 Byte aus jedem Riegel). Das ist toll wenn diese Daten auch wirklich gebraucht werden, aber es belegt das RAM nur unnötig lange und unnötig viel Platz im Cache, wenn dies nicht der Fall ist und wird dann zum Nachteil. Daher muss man eben sehen bis zu welchen Grad Prefetching Sinn macht, was aber von Anwendung zu Anwendung verschieden ist.

Was da mit "Statt dessen verteilt man die Zugriffe auf die internen Speicherbänke geschickter. Im Prinzip ist das auch Prefetching, aber eben auf einer anderen Ebene" gemeint sein soll, kann ich nicht so ganz nachvollziehen. Vermutlich sinf damit Memory Ranks gemeint, aber den Begriff Rank haben sie bei elektronik-kompendium ja ganz vermieden. Neu sind die Ranks aber nun wirklich auch nicht und vor allem dazu da Riegel mit größeren Kapazitäten zu erlauben. Da sind wir dann bei Deinem letzten Zitat, wo es auch darum geht über die CS mehr Dies ansprechen zu können.

Der erste Satz Deines letzten Zitats ist nur historisch, denn DDR4 wurde zuerst für Server genutzt und da ist ECC RAM Pflicht, aber mehr hat speziell DDR4 mit ECC auch zu tun, da bei DDR4 bzgl. ECC nichts anderes ist als bei seinen Vorgängern.

Zum Eingangspost: bcdedit /enum {badmemory} ist nur sinnvoll, wenn man auch vorher mit bcdedit /set {badmemory} badmemorylist 0x... 0x... die defekten Speicherbereiche angegeben hat und dann sollte man auch nicht vergessen noch bcdedit / set badmemoryaccess no auszuführen damit Windows diese dann auch wirklich unbenutzt lässt. Nur damit nicht jeder glaubt bei dem die Liste leer ist, sein RAM wäre deswegen auch garantiert in Ordnung.
 
@Holt
Stacked RAM sind gestapelte ICs also übereinander Angeordnet anstatt nebeneinander, HBM ist der Effekt der daraus entsteht.

Wenn jeder "Rank" seine eigenen Daten & Adress Leitungen hat, kannst diese eben Dual ansprechen auf einem Modul.
Die Idee auf Punkt-zu-Punkt Verbindungen zurück zu greifen ist ja nicht neu: http://www.bit-tech.net/hardware/memory/2010/08/26/ddr4-what-we-can-expect/2

Danke für die Ausführung bezüglich bcdedit, gilt das auch für Windows 10 Pro 14393?
Dachte es wird mehr automatisiert, so wird es ja doch wieder ein Text Adventure. :)
 
Es gibt auch Stacked RAM auf normalen DIMM Reigel, nur hat man dann deswegen eben keine (nennenswert) höhere Bandbreite oder geringere Latenz, ist also dann kein HBM. Es hat auch nicht jeder Rank eigene Daten und Adressleitungen wenn es auf einem DIMM verbaut ist, schau Dir doch mal den Pinout so eines DDR4 oder DDR3 RAMs an, da gibt es nur genau einen Satz Adress- und einen Satz Datenleitungen für alle Ranks des DIMMs. Man packt HBM ja auch direkt neben den Chip auf dessen Trägerplatine, weil man neben den kurzen Wegen eben auch sehr, sehr viele Verbindungen zu realisieren hat, denn das muss man wenn man wirklich pro Rank einen Channel haben will und kann dann auch mal locker 512 Bit Anbindung, was 8 Channels entspricht und damit gewöhnlich insgesamt mindestens 64 RAM Chips auf 8 DIMMs verteilt benötigen würde.

Also noch mal kurzgefasst: Mit Stacked RAM als HBM direkt auf dem Chip kann man jeden Rank (wobei das vom RAM abhängt) als einen Channel ansprechen, bei Stacked RAM auf einem DIMM geht dies nicht! Damit geht auch kein Dual Channel Betrieb mit nur einem DIMM, auch wenn dort Stacked RAM drauf ist!

Das mit der Punkt-zu-Punkt Verbindung bedeutet nur, dass man nur ein DIMM pro Kanal nutzen kann, dies war mal gerüchteweise bei Intels S. 2011-3 so vorgesehen, wurde aber wieder fallen gelassen, die meisten Boards unterstützen ja auch mehr als ein DIMM pro Channel und auch AM4 wird ja Dual Channel mit 2 DIMMs pro Channel haben.

Bezüglich bcdedit würde ich mal annehmen, ohne es aber nachgesehen zu haben, dass es auch für Windows 10 nicht anderes sein wird. Vielleicht wurde die Bedienung oder die Syntax des Befehls geändert, aber warum sollte man das Prinzip ändert? Linux hat das gleich auch, da kann man ebenfalls defekte RAM Bereiche ausblenden aber das muss eben immer gleich am Anfang beim Booten passieren, deshalb ist das ja auch in bcdedit drin. Ob das Automatisch gehen kann, weiß ich nicht, aber ich wüsste auch nicht wie es gehen könnte. Außer bei ECC RAM (und dem passenden System, das gehört selbstverständlich immer dazu, auch wenn ich es nicht erwähne) sind RAM Fehler ja nicht als solche zu erkennen, da man nie weiß ob das was man ausgelesen hat, auch das war was dort vorher reingeschrieben wurden. Die Ausnahme sind RAM Tests, die wissen was sie schreiben und dann auch wieder auszulesen erwarten, man müsste also einen RAM Test machen, nur reicht ein kurzer Test mit einem Muster nicht aus um alle RAM Fehler zu finden, auch Dir an was Memtest86 so an Tests macht und wie lange dies dauert. Da wird wohl keiner beim Booten drauf warten wollen.

Mit ECC RAM könnte es theoretisch automatisch laufen, nur wozu? Das ECC RAM ist ja gerade dazu da die RAM Fehler auch zu korrigieren und außerdem könnte man die Eintragungen dann zwar vornehmen, aber erst beim nächsten Booten würden sie auch aktiv sein. Ob es eine SW gibt die dies machen kann, entzieht sich aber meiner Kenntnis. Der Weg ist die RAMs mit Memtest86 zu prüfen und die Adressen wo Fehler auftreten dann einzutragen, wobei dort eben Blockadressen rein kommen und die RAM Blöcke von Windows gewöhnlich 4k groß sind, also die drei stellen rechts von der hexadezimalen Adresse wo Fehler auftrat wegfallen und der Rest nach rechts geschoben werden muss. Waren also RAM Fehler auf 0x000000013a985dbc und 0x00000001cb3c6a80c so muss der Befehl bcdedit /set {badmemory} badmemorylist 0x13a985 0x1cb3c6a sein.

--- Update ---

Wegen dem Automatischen Eintragen habe ich noch mal geschaut ob ich einen Hinweis finde ob der Windows Installer dies ggf. als Egebnis eines eigene Memtests macht, aber nichts dazu auch nicht wirklich etwas gefunden. Ich will es aber nicht ausschließen. Wenn also jemand Einträge hat die er nicht selbst eingegeben hat, dann dürften diese von dort kommen.
 
@Holt
Danke, mal sehen wie weit DDR4 Takt seitig kommt. Mein ECC DDR3-1866 läuft auch mit 2x 8GByte 2133, das würde Hand in Hand mit DDR4-2133 gehen.

Bezüglich bcdedit, muss ich nochmal in ruhe reinschauen.

Soweit ich das Testen konnte lief BOINC 3 Tage lang durch, wobei der "System File Cache" auf 25GByte angeschwollen ist, also nur ~1.6GByte RAM frei von 32GByte.
An der Auslastung (Menge) kann es nicht liegen. ;)
http://abload.de/img/boinctn-grideinstein_atrc2.jpg

€dit: BCDedit unter Windows: https://msdn.microsoft.com/de-de/windows/hardware/drivers/whea/how-whea-performs-pfa-on-ecc-memory
Es ist nur bei der Server Version aktiviert, bei der Desktop Version ist der WHEA Pfad nicht mal in der Registry vorhanden.
 
Zuletzt bearbeitet:
Ich habe folgenden RAM eingebaut:

Crucial 16GB DDR4-2400 ECC UDIMM VLP , 2 Module
http://www.crucial.de/deu/de/ct16g4xfd824a

Mainboard: ASUS ROG STRIX B350-F Gaming
CPU: Ryzen 7 1800X

Hat jemand Interesse an irgendwelchen Tests, mit Ausnahme von OC oder anderen Memory Timings?
Ich werde nicht übertakten, der Rechner wird als Arbeitsrechner produktiv verwendet.
 
Zuletzt bearbeitet:
Werde ich heute Abend prüfen, bin im Moment am Arbeiten.
 
Um Fehler zu provozieren hatte ich halt auch übertaktet und die Spannung gesenkt, damit mir der WHEA Logger in Windows 10. (Nachträglich als Ereignis hinzugefügt, was anzeigen konnte.)

Als Belastungstest für den Ram habe ich unter Windows 10 LinX verwendet, und den maximal verfügbaren Ram reservieren lassen. Memtest für Windows taugte dafür nicht !

Auf UEFI Ebene habe ich das Memtest v 7.4 von Passmark Hersteller verwendet, zeigt auch sofort Fehler an wenn die Spannung zu gering oder der Takt zu hoch ist. Leider zeigt diese Version nicht korrekt an ob ECC Korrektur an oder aus ist bzw. funktioniert. Möglich das eine neuere Version das kann.

https://www.memtest86.com/download.htm
 
ECC scheint zu funktionieren, folgende Ausgabe erhalte ich im Gnome-Terminal in Linux:
Code:
sudo dmidecode --type memory
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

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

Handle 0x0036, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x002D
Error Information Handle: 0x0035
Total Width: 128 bits
Data Width: 64 bits
Size: 16384 MB
Form Factor: DIMM
Set: None
Locator: DIMM_A2
Bank Locator: BANK 1
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 2400 MHz
Manufacturer: Micron Technology
Serial Number: 19A84B24
Asset Tag: Not Specified
Part Number: 18ADF2G72AZ-2G3B1
Rank: 2
Configured Clock Speed: 1200 MHz
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V

Handle 0x003B, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x002D
Error Information Handle: 0x003A
Total Width: 128 bits
Data Width: 64 bits
Size: 16384 MB
Form Factor: DIMM
Set: None
Locator: DIMM_B2
Bank Locator: BANK 3
Type: DDR4
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 2400 MHz
Manufacturer: Micron Technology
Serial Number: 19A848C2
Asset Tag: Not Specified
Part Number: 18ADF2G72AZ-2G3B1
Rank: 2
Configured Clock Speed: 1200 MHz
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V

In Windows 10 erhalte folgende Ausgabe:
Code:
wmic MEMORYCHIP get DataWidth,TotalWidth
DataWidth TotalWidth
64 128
64 128

Kann das jemand in dieser Form validieren?
 
Zuletzt bearbeitet:
Zurück
Oben Unten