32 GB ECC-RAM auf Sockel AM3-Board

Steffen M.

Cadet
Mitglied seit
14.04.2006
Beiträge
48
Renomée
2
Hallo zusammen,

ich nutze aktuell u.a. einen Phenom II 1090T auf einem Gigabyte GA-890FXA-UD5 (rev. 2.0) mit 16 GB RAM bestehend aus 4 Modulen des Typs "Kingston ValueRAM KVR13E9S8/4", also DDR3, 1333 MHz, Unbuffered, mit ECC. Diesen Speicher möchte ich gerne durch 4 Module des Typs "Kingston ValueRAM KVR18E13/8" ersetzen. Dabei handelt es sich ebenfalls ungepufferter Speicher, DDR3, mit ECC und 1866 MHz sowie 8 GB pro Modul. Damit sollten ja die 32 GB Systemspeicher zu schaffen sein, die ich dringend benötige.

Da der Phenom II nun schon etwas betagter ist, wollte ich hier fragen, ob jemand eine solche Konfiguration im Einsatz hat und ob Schwierigkeiten zu erwarten sind. Ich erwarte, dass ich die 1866 MHz bei zwei 8 GB-Modulen pro Speichercontroller nicht voll ausnutzen kann und es einen Rückfall auf 1600 MHz (oder im schlimmsten Fall sogar auf 1333 Mhz) geben wird - was aber ja vermutlich kein Problem sein sollte, oder sehe ich das verkehrt?

Da die 1600 MHz-Module nicht wesentlich preisgünstiger sind als die 1866er und bei einer zukünftigen Aufrüstung von Board und CPU auf eine FX9370- oder FX9590-Lösung (oder etwas Zukünftiges) der Speicher erhalten bleiben soll, sehe ich keinen Grund, zu langsameren Modulen zu greifen. Bezahlbare Intel-Lösungen fallen leider auf Grund der fehlenenden ECC-Unterstützung, die mich inzwischen schon mehrfach vor Speicherfehlern gerettet hat, aber bei Intel nur bei den teuren XEONs verfügbar ist, raus. Die Tatsache des Wechsels auf DDR4 habe ich natürlich durchaus im Hinterkopf.

Ich bedanke mich im Voraus für alle hilfreichen Tipps!

Viele Grüße
Steffen
 
Zuletzt bearbeitet:
Die Unbuffered ECC RAM unterstützen bei Intel nicht nur die teuren Xeon E5 (wovon der günstigste ein 6 Kerner für 220€ ist), sondern auch die Xeon E3 CPUs (ebenso wie sowie Celerons, Pentiums und i3) für die die passenden Boards ab 140€ und damit auch günstiger als die Boards für Xeon E5 sind, die bei 300€ losgehen, dafür aber auch mehr RAM aufnehmen, wenn bei S. 2011-3 dafür auch nur DDR4 RAM.

Ob zukünftige AMD Lösungen auch noch DDR3 RAM unterstützen, ist auch eher unwahrscheinlich, denn DDR4 dürfte DDR3 im nächsten Jahr überholen und wird auch von AMDs kommende Plattform unterstützt werden. Wenn Du unbedingt 32GB brauchst und es auf Deinem Board nicht geht, würde ich nicht auf einen FX9370 oder FX9590 setzen, die sind alt, garantiert wird es für seinen Sockel keine Leistungsstärkere CPU mehr geben haben eine hohe TDP die im Grund eine WaKü verlangt. Für den gibt auch nicht viele Boards die überhaupt die passenden Spannungswandler haben und dann noch ECC RAM unterstützen, sondern auf einen Xeon E3, deren 4. Generation auf Broadwell Basis gerade bei Anandtech getestet wurde, da hast Du mehr Performance bei viel weniger Leistungsaufnahme und dazu eine Plattform mit Boards die wirklich auf ECC Unterstützung sowie 8GB RAM Module ausgelegt sind und dies nicht nur eher zufällig nebenbei können.
 
Zuletzt bearbeitet:
@Steffen M.
Wenn dein Mainboard und das Bios ECC Unterstützen sollte es keine Probleme geben, bis auf das Herunter takten der Speicher Frequenz.
Die FX können alle mit DDR3-1866 betrieben werden, allerdings kann es hier auch zum Fall back kommen mit 4 Modulen.
Ich nutze selbst nur zwei DDR3-2133 Module mit Multi-Bit ECC Poll: http://abload.de/img/20150516_114001qoxk2.jpg

MfG
 
Wie Du nutzt Multi-Bit ECC Poll? Die Unbuffered ECC können nur Single-Bit Fehler korrigieren und Doppelfehler erkennen, aber das ECC Polling ist eine Funktion von Memtest86 um zu sehen ob während des Tests Fehler erkannt wurden:
Die RAM Controller korrigieren die Fehler selbst, aber um Auszulesen ob es Fehler gab die korrigiert wurden und ggf. dann zu reagieren wenn es Doppelbitfehler gibt die nicht korrigiert werden können, dazu braucht man eine Unterstützung durch das Betriebssystem. Bei Servern mit kritisichen Daten löst man dann z.B. eine Kernel-Panic aus um zu verhindern das korrupte Daten weitergegeben werden.
 
Wie Du nutzt Multi-Bit ECC Poll? Die Unbuffered ECC können nur Single-Bit Fehler korrigieren und Doppelfehler erkennen, aber das ECC Polling ist eine Funktion von Memtest86 um zu sehen ob während des Tests Fehler erkannt wurden: Die RAM Controller korrigieren die Fehler selbst, aber um Auszulesen ob es Fehler gab die korrigiert wurden und ggf. dann zu reagieren wenn es Doppelbitfehler gibt die nicht korrigiert werden können, dazu braucht man eine Unterstützung durch das Betriebssystem. Bei Servern mit kritisichen Daten löst man dann z.B. eine Kernel-Panic aus um zu verhindern das korrupte Daten weitergegeben werden.
Wenn ich die Funktion ECC Injektion auswähle, dann schaltet der PC direkt aus.
Ein einschalten lässt das System normal hochfahren ohne Fehlermeldungen. (UEFI oder OS)

Hab mal die üblichen verdächtigen unter Win 10 laufen lassen: http://abload.de/img/ecc_overview_win10pron4u1q.jpg
Was genau könnte denn: Checksum for Bytes 0 - 116 = BF56 bedeuten? (SIV64)
1 Byte hat doch 8 Bit?
 
Das dürfte die Checksumme für die SPD Informationen sein, das steht ja auch unter SPD Informationen, man muss ja auch sicher sein, dass die Informationen aus dem SPD korrekt ausgelesen wurden. Hier findest Du unter 4.2 die Formel, wie Du hier sehen kannst bezieht sich das noch auf die älteren Versionen bei denen die CRC im Byte 63 stand und nur die Bytes 0 bis 62 sicherte, hier sieht man dann wie es bei DDR3 RAM konkret aussieht:
Byte 0
Number of Serial PD Bytes Written/ SPD Device Size/ CRC Coverage

Bit 3 to Bit 0 describes the total size of the serial memory actually used in the EEprom for the Serial Presence Detect data. Bit 6 to Bit 4 describes the number of bytes available in the EEprom device, usually 128byte or 256 byte. On top of that, Bit 7 indicates whether the unique module identifier covered by the CRC encoded on bytes 126 and 127 is based on (0-116byte) or based on (0-125byte)..

(When CST EZ-SPD Programmer is used: Simply select items from 3 tables and automatically calculate the final hex number)

The most common one used is:
Total SPD Bye = 256
CRC Coverage = 0-116Byte
SPD Byte used = 176 Byte
Resulting code is 92h
....
Byte 126-127
SPD Cyclical Redundancy Code (CRC)

This two-byte field contains the calculated CRC for previous bytes in the SPD. A certain algorithm and data structures are to be followed in calculating and checking the code. Bit 7 of Byte 0 indicates which bytes are covered by the CRC.

Das hat also wie Du siehst mit dem RAM selbst überhaupt nichts zu tun, deshalb steht es ja auch unter SPD Field Description. Was für Fehler hast Du denn injeziert, dass der Rechner ausgeht? Wenn es bei SingleBit Fehler passiert wäre es schlecht, bie müssten so korrigiert und nur gezählt werden, bei Doppelbitfehlern wäre es für ein Consumerboard ja in Ordnung, denn da läuft ja meist ein normaler Windows und keiner Server-OS und die normalen Windowsversionen unterstützen meines Wissen eben auch kein Auslesen der RAM Fehlerzähler und keine Reaktion auf erkannte aber unkorrigierbare Fehler. Es wäre dann sogar sehr konsequent wenn das BIOS in dem Fall selbst reagiert und den Rechner deaktiviert, damit es eben keine korrupten Daten gibt, wobei das Ausschalten natürlich auch zu Problemen führen kann, gerade für das Filesystem.
 
@Holt
Moin, ah danke das wird es sein, die Checksumme vom SPD, dort muss ja auch drin stehen, dass ECC an ist.

Weiter oben ist der Eintrag hier zu finden:
Module Memory ECC Tag Width and Bus Width: 0x0B ECC 8 Bus 64
72Bit pro Modul mit jeweils 18 Chips a 4Gb: http://abload.de/image.php?img=20141022_163214uqorw.jpg
Unter Memory Controller liest SIV ECC Chip-Kill Verfahren aus.

Das abschalten passiert recht selten, sofern ich es nicht mit Memtest provoziere, blaue Bilder habe ich schon lange keine mehr. ;)
 
Das ist möglich, schau mal hier S. 167f.. Da steht auch: "Chip Kill mode can only be used in a 128-bit data width configuration." Wenn Du also einen Riegel entfernst, sollte dort nicht mehr Chip-Kill stehen, denn dann wird es nicht mehr unterstützt. Das ist auch sinnvoll, denn sonst wären zu viele Zugriffe nötig und das würde das RAM verlangsamen und die Leistungsaufnahme unnötig steigern.
 
Memtest86 und andere Software ist übrigens lange nicht perfekt. Das hat z.B. bei meinem AM1 definitiv falsche ECC Informationen angezeigt (sollte eigentlich mittlerweile behoben sein das Problem, nachdem ich das gemeldet hatte). Am Besten schaut man in die Specs von AMD und ließt/kontrolliert die Werte manuell. Die SPD-Informationen alleine reichen nicht um zu sagen, dass ECC aktiv ist.
 
@Holt
OK, also nur im Dual Channel, es werden zumindest 128Bit ausgelesen.
Das mit dem Single Modul ist ein Versuch Wert, danke!

Memtest86 und andere Software ist übrigens lange nicht perfekt. Das hat z.B. bei meinem AM1 definitiv falsche ECC Informationen angezeigt (sollte eigentlich mittlerweile behoben sein das Problem, nachdem ich das gemeldet hatte). Am Besten schaut man in die Specs von AMD und ließt/kontrolliert die Werte manuell. Die SPD-Informationen alleine reichen nicht um zu sagen, dass ECC aktiv ist.
Ich habe ein Pro Lizenz von Memtest86 V6.0.0, denen erzähle ich was wenn das nicht richtig ausliest! :)
Auch HWinfo64 und AIDA lesen aktives ECC aus, von daher bin ich zuversichtlich, dass es auch läuft. Zumal es im UEFI explizit aktiviert (enabled) ist.

Gruß
 
@Holt
OK, also nur im Dual Channel, es werden zumindest 128Bit ausgelesen.
Das mit dem Single Modul ist ein Versuch Wert, danke!


Ich habe ein Pro Lizenz von Memtest86 V6.0.0, denen erzähle ich was wenn das nicht richtig ausliest! :)
Auch HWinfo64 und AIDA lesen aktives ECC aus, von daher bin ich zuversichtlich, dass es auch läuft. Zumal es im UEFI explizit aktiviert (enabled) ist.

Gruß

Wie gesagt, den einen AM1 Bug hab ich denen gemeldet, und der sollte eigentlich behoben sein. Ich hab kein anderes AMD-System mit welchem ich die Werte checken könnte. Du brauchst nur den passenden BIOS and Kernel Developer’s Guide und eine Software wie RWEverything.
 
@BoMbY
Ein Auszug aus dem Log von Memtest86 v6 im UEFI Mode gebootet:
MemTest86 V6.0.0 Pro Build: 1000 (64-bit)
- Getting memory controller info
- find_mem_controller - found AMD 15h (1022:1602) at 0-24-2
- AMD 10h and greater chipset init
- DRAM config low=0B090000
- MCA NB config=4A700044
- NbMcaLogEn is disabled. Enabling...
- MCA Extended NB config=E20BE281 [EccSymbolSize=x8]
- MC4_CTL=00000000FFFFFFFF
- MC4_CTL_MASK=0000000000780400
- MCG_CTL low=00000077
- find_mem_controller - AMD 15h (1022:1602) at 0-24-2
- find_mem_controller - AMD 15h ECC mode: detect: yes, correct: yes, scrub: no, chipkill: no
- ECC polling enabled
- Successfully located the PI MpService protocol.
- BSP is Proc 0
- This platform has 8 logical processors of which 8 are enabled.
Scheinbar doch kein chipkill, aber ECC wird korrekt ausgelesen wenn ich es abschalte im UEFI:

- find_mem_controller - AMD 15h ECC mode: detect: no, correct: no, scrub: no, chipkill: no
- ECC polling disabled

Wonach muss ich den Suchen bei den MSR Registern?
 
Vermutlich bei D18F3x44 (MCA NB Configuration) Bit 22 == 1 heißt ECC aktiv, Bit 23 == 1 heißt ChipKill aktiv. Scrubbing ist wohl irgendwo anders.
 
Keine Ahnung wie Memtest86 damit umgeht, aber bei Memtest86+ wird meine ich versucht das ECC zu deaktivieren, denn man will ja das RAM selbst auf Hard-Errors testen. Klar kann man auch alternativ im Ramtest mit ECC die Fehler abfangen und anzeigen, aber ich würde für einen RAM Test das ECC erst einmal deaktivieren, denn wenn man schon Fehler im RAM hat steigt natürlich das Risiko von Doppelbitfehlern an.
 
@Steffen:
Ich hab es selber nie ausprobiert (mir reichen 16GB), aber ich würde denken, wenn Gigabyte im Bios nicht großen Mist gebaut hat, dann sollte es gehen mit 4x8GB.

Aber: Kannst Du mit Deinem Gigabyte denn überhaupt ECC einschalten? Wenn im Bios dazu nichts zu finden ist, dann lässt sich ECC auch nicht nutzen AFAIK. Die zusätzlichen 8bit stören nicht, bringen dann aber auch nichts.

Mir war bisher immer so, dass Gigabyte auf den AMD-Plattformen KEIN ECC unterstützt. Halbwegs sicher ist man da nur bei Asus, und die schreiben es dann auch explizit rein in die Specs.....

Ev. kann man noch was mit MSR-Bastelei erreichen, wobei ich nicht weiß, ob man speziell die entsprechenden Speicher-Register noch nachträglich beschreiben kann..... Das habe ich zuletzt zu Win95-Zeiten gemacht, als man noch die config.sys für Basteleien im Real-Mode bei Start hatte.....


edit: Hier gibt Gigabyte ja selber an, es laufen bis 32GB. Sollte also gehen. Nur wie ich schon sagte, von ECC ist keine Rede, ich gehe davon aus, dass Du hier ECC-RAM vergeblich einbaust.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Die Unbuffered ECC RAM unterstützen bei Intel ... die Xeon E3 CPUs (ebenso wie sowie Celerons, Pentiums und i3) für die die passenden Boards ab 140€ ...
Das ist aber immer noch erheblich teurer als ein AM3+-Board von ASUS und eine FX-83xx-CPU.

--- Update ---

Vermutlich bei D18F3x44 (MCA NB Configuration) Bit 22 == 1 heißt ECC aktiv, Bit 23 == 1 heißt ChipKill aktiv. ...
In D18F3xE8 (Read-only) kann man sehen, ob die Northbridge ECC überhaupt unterstützt (Bit 4 == 1 ChipKill, Bit 3 == 1 ECC).

--- Update ---

Wobei die Frage ist was "capable of handing" jetzt bedeuten soll. Heißt es nur das es damit läuft, was man für fast alle Boards sagen kann oder bedeutet es auch, dass ECC funktioniert?
Das war ja auch das Problem bei AM1.
Die Leute haben ECC reingesteckt und irgendeine obskure Software hat dann auch ECC gemeldet.
Die AM1-APUs können aber gar kein ECC (siehe oben).
 
Bist Du sicher das AM1 generell kein ECC RAM unterstützt?
Alle bisher verkauften AM1-APUs (und FT3 Kabinis und Beemas) unterstützen kein ECC.
Siehe D18F3xE8 (Read-only) Bit 4 und 3.

Dann soll ASUS mir eine AM1-APU senden, die ECC unterstützt.
Papier ist geduldig.
Selbst AMD behauptet, sie würden ECC unterstützen.

Im übrigen wurde das schon gefühlt tausend Mal durchgekaut :-(
 
Zuletzt bearbeitet:
Zurück
Oben Unten