Verständnisfrage zum Memory Scrubbing
- Ersteller SPINA
- Erstellt am
Benötige ich Memory Scrubbing (als Redirect oder Background), damit ECC vollfunktionsfähig ist und mehr als Parity angewandt wird?
Irgendwie sind die Quellen, die man so bei Tecchannel, Wikipedia und so weiter findet, in dem Punkt nicht ganz eindeutig.
Mir reicht eigentlich simples ECC. Ich brauche kein ChipKill und andere Finessen. Aber ich möchte schon eine Fehlerkorrektur haben.
Also es soll nicht nur Fehler erkannt und gemeldet werden, sondern sie sollen auch gleich (wenn möglich) behoben werden.
Wie kann ich sicherstellen (ohne Pins an den DIMMs abzukleben), dass mein Speicher auch genauso arbeitet?
Prozessor ist ein AMD Phenom X4 9550 auf einem ASUS M3N72-D mit Kingston KVR800D2E6K4/8G.
Irgendwie sind die Quellen, die man so bei Tecchannel, Wikipedia und so weiter findet, in dem Punkt nicht ganz eindeutig.
Mir reicht eigentlich simples ECC. Ich brauche kein ChipKill und andere Finessen. Aber ich möchte schon eine Fehlerkorrektur haben.
Also es soll nicht nur Fehler erkannt und gemeldet werden, sondern sie sollen auch gleich (wenn möglich) behoben werden.
Wie kann ich sicherstellen (ohne Pins an den DIMMs abzukleben), dass mein Speicher auch genauso arbeitet?
Prozessor ist ein AMD Phenom X4 9550 auf einem ASUS M3N72-D mit Kingston KVR800D2E6K4/8G.
Ich habe gerade herausgefunden, dass ChipKill doch möglich ist. Dafür muss man nur von Unganged auf Ganged umstellen. Warum auch immer.
Nun kann ich mich nur nicht entscheiden, ob mir Unganged oder ChipKill wichtiger ist. Da ich viele multithreaded Anwendungen nutze, wohl Unganged.
Und dann bleibt noch die Frage danach, wie wichtig das Scrubbing ist. Also mein L1 und L2 Cache wird gescrubt. L3 Cache und DRAM dagegen nicht.
Also wie ich es bisher verstanden habe ist Memory Scrubbing ein fortlaufender Test, aber welche Auswirkungen der Verzicht hat, ist mir noch unklar.
Denn wenn die Fehlerkorrektur bei jeder E/A-Operation greift, dann frage ich mich wieso es überhaupt so etwas wie Scrub Redirect gibt.
Bei den Workstation Boards, die ich kenne, wählt man einfach Basic, Super,... und das wars. Da war ECC bisher immer viel feiner zu konfigurieren.
Ich frage nur, weil ich hier mit dem M3N72-D ein normales Desktop Board habe. Da macht man sich mehr Gedanken über die korrekte Implementierung.
Nun kann ich mich nur nicht entscheiden, ob mir Unganged oder ChipKill wichtiger ist. Da ich viele multithreaded Anwendungen nutze, wohl Unganged.
Und dann bleibt noch die Frage danach, wie wichtig das Scrubbing ist. Also mein L1 und L2 Cache wird gescrubt. L3 Cache und DRAM dagegen nicht.
Also wie ich es bisher verstanden habe ist Memory Scrubbing ein fortlaufender Test, aber welche Auswirkungen der Verzicht hat, ist mir noch unklar.
Denn wenn die Fehlerkorrektur bei jeder E/A-Operation greift, dann frage ich mich wieso es überhaupt so etwas wie Scrub Redirect gibt.
Bei den Workstation Boards, die ich kenne, wählt man einfach Basic, Super,... und das wars. Da war ECC bisher immer viel feiner zu konfigurieren.
Ich frage nur, weil ich hier mit dem M3N72-D ein normales Desktop Board habe. Da macht man sich mehr Gedanken über die korrekte Implementierung.
Zuletzt bearbeitet:
Da habe ich noch was gefunden (AMD macht es aber auch spannend):
Mein Phenom X4 (B3) unterstützt nur eine Symbol Size von x4. Bei den verwendeten x8 DIMMs gibt es somit kein ChipKill.
Oder allenfalls nur ein "ChipKill-Lite" auf Standard ECC Niveau. Anders sähe es mit einem Phenom II X6 (E0) aus.
Zumindest steigert es die Erkennbarkeit von 2-Bit Fehlern von 99,5% auf 100%. Aber eine Korrektur ist weiter nicht möglich.
Bleibt nur die Frage, wieso das Status Register (ChipKillECCEn) meiner CPU jetzt meldet, der x4-Mode wäre aktiv.
Ergänzung: In einem älteren BIOS & Kernel Developer Guide stand es noch einmal etwas deutlicher:
Jedenfalls bei den meist verwendeten 128M x 8-bit (bei 2GB UDIMMs) oder 256M x 8-Bit (bei 4GB UDIMMs) Chips.
Erst der Thuban würde die nötige x8 Symbol Size mitbringen, um die zur Verfügung stehende DRAM Width abzudecken.
Deswegen kann man also beim Agena und Deneb getrost bei Unganged bleiben und hat dadurch keine Nachteile.
Eigentlich ein ziemlicher Lapsus seitens AMD. Beim Barcelona und Shanghai ist das schon ein gewichtiger Nachteil.
Zwar gibt es hochkapazitive x4 RDIMMs, aber da wäre immer noch die geringere NUMA Effizienz durch Ganged.
Mein Phenom X4 (B3) unterstützt nur eine Symbol Size von x4. Bei den verwendeten x8 DIMMs gibt es somit kein ChipKill.
Oder allenfalls nur ein "ChipKill-Lite" auf Standard ECC Niveau. Anders sähe es mit einem Phenom II X6 (E0) aus.
Zumindest steigert es die Erkennbarkeit von 2-Bit Fehlern von 99,5% auf 100%. Aber eine Korrektur ist weiter nicht möglich.
Bleibt nur die Frage, wieso das Status Register (ChipKillECCEn) meiner CPU jetzt meldet, der x4-Mode wäre aktiv.
Übrigens sehe ich gerade, dass das was AMD oben in der Tabelle als ChipKill bezeichnet, gar kein ChipKill ist.
AMD spricht dort nur von der Behebbarkeit von 1-Bit Fehlern. Das beherrscht selbst Standard ECC-RAM.
ChipKill sollte aber in der Lage sein bis zu 4-Bit (!) Fehler zu beheben und bis zu 8-Bit (!) Fehler zu erkennen.
Aber scheinbar stellt AMD lediglich auf die Ausgleichbarkeit des Defekts einzelner DRAM Chips ab.
AMD spricht dort nur von der Behebbarkeit von 1-Bit Fehlern. Das beherrscht selbst Standard ECC-RAM.
ChipKill sollte aber in der Lage sein bis zu 4-Bit (!) Fehler zu beheben und bis zu 8-Bit (!) Fehler zu erkennen.
Aber scheinbar stellt AMD lediglich auf die Ausgleichbarkeit des Defekts einzelner DRAM Chips ab.
Das heißt ChipKill ist beim Agena und Deneb nur eingeschränkt mit den zur Zeit gängigen Unbuffered Modulen möglich.
Jedenfalls bei den meist verwendeten 128M x 8-bit (bei 2GB UDIMMs) oder 256M x 8-Bit (bei 4GB UDIMMs) Chips.
Erst der Thuban würde die nötige x8 Symbol Size mitbringen, um die zur Verfügung stehende DRAM Width abzudecken.
Deswegen kann man also beim Agena und Deneb getrost bei Unganged bleiben und hat dadurch keine Nachteile.
Eigentlich ein ziemlicher Lapsus seitens AMD. Beim Barcelona und Shanghai ist das schon ein gewichtiger Nachteil.
Zwar gibt es hochkapazitive x4 RDIMMs, aber da wäre immer noch die geringere NUMA Effizienz durch Ganged.
Zuletzt bearbeitet:
Also um doch nochmal auf die ursprüngliche Frage nach dem memory scrubbing zurückzukommen:
So wie ich das verstehe, wird beim scrubbing im Hintergrund nach und nach jede Speicheradresse abgefahren und geprüft, obs nen ECC Fehler gibt bei Zugriff oder nicht. Das kann wohl mit unterschiedlicher Priorität und Intensität erfolgen, was die in so manchem Bios reichhaltigen und leider nur kryptisch beschriebenen Optionen erklärt. Grundsätzlich sollte ECC aber auch ohne scrubbing funktionieren und das tun, was es soll, nämlich bei jedem Schreiben die Paritäts bzw. ECC-Zusatzbits mitschreiben und beim Lesen vergleichen, ob das immer noch passt. Mindestens single-bit Fehler werden dann auch korrigiert. So wie ich das sehe, machen die Asus-Desktop-Boards das still und heimlich. Vermutlich muss man die entsprechenden MSRs auslesen, wenn man wissen will, ob ein Bit faul ist und dauernd korrigiert wird.
Zum Chipkill, finde ich jetzt nicht sooo einen großen Lapsus. In Servern dürften in der Tat meist buffered dimms mit x4 chips stecken, da wird der Chipfehler ja immerhin dann sicher erkannt auch im unganged mode. Muss dann halt reichen, dass das System dann stehen bleibt und sich nicht weiter verrechnet.
Im Desktop/Workstation würde ich nie auf unganged verzichten. Ich denke, mit normalem ECC sind wir da wunderbar unterwegs.....
So wie ich das verstehe, wird beim scrubbing im Hintergrund nach und nach jede Speicheradresse abgefahren und geprüft, obs nen ECC Fehler gibt bei Zugriff oder nicht. Das kann wohl mit unterschiedlicher Priorität und Intensität erfolgen, was die in so manchem Bios reichhaltigen und leider nur kryptisch beschriebenen Optionen erklärt. Grundsätzlich sollte ECC aber auch ohne scrubbing funktionieren und das tun, was es soll, nämlich bei jedem Schreiben die Paritäts bzw. ECC-Zusatzbits mitschreiben und beim Lesen vergleichen, ob das immer noch passt. Mindestens single-bit Fehler werden dann auch korrigiert. So wie ich das sehe, machen die Asus-Desktop-Boards das still und heimlich. Vermutlich muss man die entsprechenden MSRs auslesen, wenn man wissen will, ob ein Bit faul ist und dauernd korrigiert wird.
Zum Chipkill, finde ich jetzt nicht sooo einen großen Lapsus. In Servern dürften in der Tat meist buffered dimms mit x4 chips stecken, da wird der Chipfehler ja immerhin dann sicher erkannt auch im unganged mode. Muss dann halt reichen, dass das System dann stehen bleibt und sich nicht weiter verrechnet.
Im Desktop/Workstation würde ich nie auf unganged verzichten. Ich denke, mit normalem ECC sind wir da wunderbar unterwegs.....