ECC Speicher sinnvoll? [Archiv]

Gast

2010-12-29, 17:59:54

Hallo!

Da ich durch Zufall herausgefunden habe, dass die Asus Mainboards für Sockel AM3 auch ECC Speicher unterstützen bin ich ins grübeln gekommen.

Ich habe vor kurzem einen Artikel gelesen, bei dem herausgefunden wurde, dass Speicherfehler doch häufiger auftreten, als bisher angenommen. Die Quelle habe ich nicht mehr.

Jetzt stellt sich mir die Frage, ob ich bei meinen neuen Kisten gleich alles mit ECC Speicher bestücken soll. Viel teurer ist das ganze auch nicht (es passt nur unbuffered ECC rein, kein registered), also warum nicht?
Probleme die mir einfallen würden: Sind denn alle (oder wenigstens die meisten) neuen (oder auch älteren, wo es mir noch nicht klar war) Mainboards (mit AMD Chipsatz) befähigt, mit ECC Speicher umzugehen?

Erziele ich bei Ebay oder sonstwo auch gute Wiederverkaufspreise? Über kurz oder lang, da bin ich mir sicher, verkaufe ich die Sachen auch wieder. Wenn keiner weiß was ECC ist, und es nirgendwo unterstützt wird, kann ich mir vorstellen, dass ich nen Wertverlust habe.

Falls das irgendwo relevant ist: Die ungefähre Bestückung der zukünftigen Maschinen kann ich auch nennen, falls das wichtig wäre.

Workstation 4GB-8GB DDR3 1333MHz (läuft ~12h/d)
Server 2GB-4GB DDR31333MHz (läuft 24/365)
Mediacenter 1GB-2GB DDR3 1333MHz (läuft ~6h/d)

Übertaktet wird bei grundsätzlich nichts, die Kisten (also Server und Workstation) müssen 100% zuverlässig sein. Ins Mediacenter/HTPC würde dann auch nur der spezielle Speicher reinkommen, weil ich mich kenne: Es wird desöfteren mal was an den Kisten verändert und dann kommen wieder neue Computer dazu oder es wird was getauscht oder aufgestockt. Da ist es nicht schlimm, wenn jeder Computer mit dem gleichen RAM bestückt ist. Ich denke ihr versteht was ich meine.

DerRob

2010-12-30, 13:35:15

Wenn irgendwelche Rechenfehler oder Programmabstürze existenzbedrohend sind, würde ich es machen.

Spasstiger

2010-12-30, 14:20:24

Ich würde ECC-Speicher nur verwenden, wenn er eine vernünftige Spezifikation hat (DDR3-1333 CL9 oder schneller) und günstiger ist als Non-ECC-Speicher mit der gleichen Spezifikation.
Unterstützen überhaupt alle AM3-Prozessoren ECC?

Gast

2010-12-30, 14:56:57

Bisher sind weder Programmabstürze noch Rechenfehler existenzbedrohend, könnten es aber später werden und würden jetzt schon sehr unangenehm sein.

Der schnellste auf Geizhals gelistete DDR3 ECC Speicher hat die von Spasstiger genannten Werte, 1333MHz und CL7 gibts leider nicht.

Ich finde leider kein Dokument, welches über die Tauglichkeit der CPUs etwas aussagt. Diverse Mainboard Handbücher die ich bisher gelesen habe, lassen allerdings darauf schließen, dass jede CPU die in eben diesen Boards funktioniert auch mit dem ECC Speicher funktioniert.
Diese Mainboards sind auch wirklich "Consumer" Boards. Die Hersteller hätten kaum diese Unterstützung eingebaut, wenn die CPUs das nicht verwenden könnten. Und für AM3 gibt es nur Sempron, Athlon und Phenom CPUs. Das sind alles "normale Consumer" CPUS.

Ein Preisvergleich mit Kingston Modulen zeigt:
1GB normal: 10€
1GB ECC: 13€
2GB normal: 19€
2GB ECC: 23€
4GB normal: 37€
4GB ECC: 45€

Auf keinen Fall werden die ECC Typen sogar günstiger sein. Das war mir klar. Aber viel teurer sind sie auch nicht. Dafür kommen bei mir nur sehr günstige CPUs rein...

Spasstiger

2010-12-30, 15:01:52

Wenns dir um die paar Euro nicht geht, kannst du ja ECC-Speicher kaufen. Im Wiederverkauf wirds natürlich problematisch.
Die ECC-Funktion würde ich persönlich nur beim Server nutzen, da man von diesem einen Dauerbetrieb erwartet. ECC-Speicher schützt übrigens auch nicht vor einem Absturz, er verringert nur die Wahrscheinlichkeit, dass der PC aufgrund fehlerhaft übertragener Daten vom/zum RAM abstürzt. Von 95% Verfügbarkeit kommst du dann vielleicht auf 99% Verfügbarkeit (Werte sind aus der Luft gegriffen).

eraser-x

2010-12-30, 15:07:40

wenn du ein stabiles system (in naher zukunft bauen )willst das eben nicht zum surfen oder zocken gedacht
zb eine workstation oder eine serverplattform
dann ist ecc schon gut
bei ecc kommt es aber eben nicht auf latenzen an sondern viel mehr das der speicher
a)läuft
b)eben fehlerfrei rennt
c)er ewig so weiter fehlerfrei bleibt :D

speed ist nicht immer alles zuverlässigkeit ist manchmal mehr wert

S940

2010-12-31, 11:51:28

Ich machs bei meinem nächsten System (vermutlich Bulldozer) auch so, aus dem Grund, den Du genannt hast: Die RAMs sind nicht über Gebühr teurer. Also wieso nicht ?

Dazu kommt noch, dass heutige CPus immer mehr Caches & bessere Prefetcher haben, da wird RAM Speed immer unwichtiger. Irgendwo hatten sie mal nen LGA1366 Prozessor im single Channel laufen lassen, das gab zwar ein paar Einbrüche, aber viel wars nicht. Insofern mach ich mir da bei Dual Channel keine Gedanken über die vermeintliche Leistung. Mit Bulldozer wird dann eh 1866 RAM Standard, da sollte Kingston dann auch schnellere Module anbieten, mit den neuen 32nm RAM Chips ist das auch kein Problem.

Zu den Prozessoren:
Alle AM3 CPus unterstützen ECC, aber die Crux ist der BIOS Support der Mainboards. Denn die ECC Funktion muss damit freigeschalten werden, ähnlich wie die ganzen anderen CPU Parameter.

Hat Dein BIOS das nicht, schaust Du in die Röhre.

Erfahrungsgemäß hat Asus das immer im BIOS dabei, nur bei ein paar low-cost Teilen sparen sie sich das. Gigabyte biete es bei ein paar high-end Bretter mit 790/890FX an. Ansonsten hab ich noch was von BIOSTAR gehört, wenn ich mich recht erinnere. Am besten zu dem Thema ist die Kompatibilitätsliste der Kingston ECC RAMs, die listen eigentlich alles an Brettern auf.

ciao & viel Spass

Alex

P.S: NOch zu den Wiederverkaufspreisen:
Die Module laufen auch problemlos in einem Brett, das kein ECC kann. Ist ja nur 1 RAM Chip mehr, der dann ungenutzt bleibt. Wichtig ist, dass die Module unbuffered sind, und nicht registered, denn das ginge dann nicht. Aber unbuffered ECC laufen auch unbuffered non-ECC, kein Problem.

Gast

2010-12-31, 14:19:37

S940, du hast mir jetzt noch mein Totschlagargument geliefert: Ich wusste nicht, dass die ECC DIMMs auch in normalen Mainboards laufen.
Das kann ich natürlich beim Verkauf angeben. Den Speicherverlust kann ich auch angeben, auch wenn sich der in Grenzen hält.
Oben habe ich übrigens behauptet, dass der verfügbare Speicher "CL7 und 1333MHz" nicht hat, was auch stimmt. Spasstiger wollte allerdings nur CL9 und 1333MHz. Diesen gibts schon!

Da ich vermutlich noch bis mind. Februar warten werde, bis ich alle Plattformen hier ersetze oder aufbaue, werdens bei mir wohl auch allesamt Bulldozer werden.
Da kann ich dann auch noch hoffen, dass es auch CPUs gibt, die noch weniger TDP haben als 45W, dann kann ich die CPUs sogar noch ganz ohne Probleme passiv kühlen.

Ich bedanke mich für eure Hilfe und kann nun guten Gewissens die neuen Systeme planen!

Vielen Dank!

DerRob

2010-12-31, 15:09:16

Den Speicherverlust kann ich auch angeben, auch wenn sich der in Grenzen hält.
Speicherverlust gibts nicht. Normaler Speicher speichert 8 Bit pro Byte, ECC-Speicher speichert einfach mehr Bits pro Byte, werden die nicht genutzt, verhält er sich wie normaler Speicher. Ein 2 GB Modul speichert also auch 2 GB, egal ob nun ECC genutzt wird, oder nicht.

S940

2010-12-31, 18:37:24

Das kann ich natürlich beim Verkauf angeben. Den Speicherverlust kann ich auch angeben, auch wenn sich der in Grenzen hält.Den gibts nicht, siehe unten.

Da ich vermutlich noch bis mind. Februar warten werde, bis ich alle Plattformen hier ersetze oder aufbaue, werdens bei mir wohl auch allesamt Bulldozer werden.Naja, Bulldozer kommt erst im Mai, aber Du kannst wenigstens versuchen bereits AM3+ Mainboards zu bekommen, die sollten früher im Februar / März kommen.

Speicherverlust gibts nicht. Normaler Speicher speichert 8 Bit pro Byte, ECC-Speicher speichert einfach mehr Bits pro Byte, werden die nicht genutzt, verhält er sich wie normaler Speicher. Ein 2 GB Modul speichert also auch 2 GB, egal ob nun ECC genutzt wird, oder nicht.Ja, aber wo kommen die "mehr Bits" pro Byte denn hin ? Dafür gibts nen zusätzlichen Chip auf den ECC Modulen. Meistens hat man 8 Chips, auf ECC Modulen hat man dann 9, wobei der 9te Chip eben die ECC Daten aufnimmt. Die Nutzkapazität ist in beiden Fällen also gleich, z.B. 2 GB, aber absolut hat man bei ECC Modulen halt nen Chip mehr.

Mit ein Grund weswegen die ECC Module etwas teurer sind, bzw. das Totschlagargument vor ~20 Jahren, mit dem man das Paritiy Bit (Vorläufer von ECC) damals abschaffte. Damals waren RAM Chips sündhaft teuer, da sparte man gutes Geld, wenn man nur 8 statt 9 Chips verbauen mußte.

Aber heutzutage für die paar Euro ... witzlos.

Aja:
Ich habe vor kurzem einen Artikel gelesen, bei dem herausgefunden wurde, dass Speicherfehler doch häufiger auftreten, als bisher angenommen. Die Quelle habe ich nicht mehr.Mir fiel gerade ein, dass das - glaube ich - ne Studie bei google war. Falls DU das mal nochmal suchen willst.

Guten Rutsch

Alex

Gast

2010-12-31, 22:32:10

http://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html

Nochmal vielen Dank an alle!

DerRob

2011-01-01, 00:53:47

Ja, aber wo kommen die "mehr Bits" pro Byte denn hin ? Dafür gibts nen zusätzlichen Chip auf den ECC Modulen. Meistens hat man 8 Chips, auf ECC Modulen hat man dann 9, wobei der 9te Chip eben die ECC Daten aufnimmt. Die Nutzkapazität ist in beiden Fällen also gleich, z.B. 2 GB, aber absolut hat man bei ECC Modulen halt nen Chip mehr.
Ich war mir nicht ganz sicher, ob es nur ein Chip mehr ist. ECC heißt ja Error-Correcting Code oder Error Checking and Correction, aber reicht denn nur ein Bit mehr schon aus, um auftretende Fehler auch schon korrigieren zu können? Das neunte Bit speichert doch die Parität, sind z.B. eine gerade Anzahl Bits gesetzt, ist es 0, sind eine ungerade Anzahl gesetzt, ist es 1. Wenn ein Bit jetzt kippt, stimmt die Parität nicht mehr, und man kann den Fehler so korrigieren. Aber wie stellt man jetzt fest, welches Bit nicht mehr in Ordnung ist?

Ric

2011-01-01, 01:46:45

http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren

DerRob

2011-01-01, 02:04:25

http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren
Ja, das hab ich mir schon angeschaut, aber in dem Beispiel werden 12 Bits zur Fehlererkennung in 8 Bits genutzt, ECC Speicher hat aber nur 9 Bits statt 8. Aber wenn ich das richtig verstehe, werden da mehrere Bytes zusammengefasst, statt 8/9 Bit werden also gleich 64/72 Bit verwendet. Weiß jemand, welches Fehlerkorrekturverfahren bei ECC-Ram genutzt wird?

Ric

2011-01-01, 02:26:53

Genau das dargestellte Verfahren wird genutzt.

Das Verfahren nennt sich Hamming-Code (http://de.wikipedia.org/wiki/Hamming-Code).

Gast9t99

2011-01-01, 03:37:58

Mars81

2011-01-01, 11:38:50

Man kann ecc auch deaktivieren und so die dimms testen. dann wird man schon feststellen ob der hersteller bei server-ram billigen schrott verbaut ;)

Gast9t99

2011-01-01, 16:54:50

Man kann ecc auch deaktivieren und so die dimms testen. dann wird man schon feststellen ob der hersteller bei server-ram billigen schrott verbaut ;)

Hast du das schonmal probiert? Ich bin mir nicht sicher, ob sich ECC wirklich komplett abschalten läßt. Ich glaube das läuft immer mit (wird halt nur nichtmehr durch die CPU ausgewertet).

Noch was anderes: Wenn man ECC für den L2/L3-Cache einer CPU aktiviert, verliert man bis zu 10% Leistung. Weiß jemand wie hoch der Performanceverlust durch ECC bei DDR3-Ram ist? Mit deaktiviertem ECC testen ist zwecklos - das läuft im Zweifel immernoch mit. Man bräuchte also schon 2 Module mit identischen Chips aber unterschiedlicher Bauweise um das zu überprüfen. Wenn ich es richtig verstanden habe, liefern ECC-Dimms nur eine zusätzliche Checksum für jeden Speicherzugriff ab. Die Auswertung (ob korrigiert werden muß oder nicht) müßte dann durch den IMC oder gar die CPU erfolgen. Und das bei jedem Speicherzugriff. Ich kann mir nicht vorstellen, daß jemand das freiwillig aktiviert. - Es sei denn es gibt einen handfesten Grund. Und dieser Grund wäre bei mir Anlaß genug den defekten Speicher auszubauen und postwendend wieder zurückzuschicken.

Meine Meinung: Ich halte ECC bei Dimms (auch im Serverbereich) für eine reine Beruhigungspille aus Zucker (die Wirkung ist rein psychologisch). Wenn ich mich nicht irre, gibt es sogar kein einziges i5/i7-Board (1156), welches ECC-Ram unterstützt. Nichtmal die richtig teuren:
http://www.mix-computer.de/html/product/detail.html?articleId=385189
Und die Boards funktionieren im großen und ganzen trotzdem. Wenn ich richtig informiert bin, werden die meisten neuen SandyBridge-CPUs ebenfalls ohne ECC-Unterstützung ausgeliefert (bis auf die richtig teuren). Es stellt sich also die Frage - WARUM geht man bei intel ein solches RISIKO ein (oder auch nicht). ;)

Es kann natürlich sein, daß ECC im Serverbereich doch sinnvoll ist, weil dort gelegentlich 'recycelte'/'rundumerneuerte' Geräte zu absolut konkurrenzfähigen Preisen im Umlauf sind. Wer kann schon sagen wie ausgelutscht dort manche ECC-Module sind, die von Generation zu Generation weitervererbt wurden (wenn der Mann vom Service mal wieder in die große Restekiste gegriffen hat)?[/Sarkasmus]

Gast

2011-01-01, 17:18:10

Als Threadersteller find ich diese Betrachtungsweiße interessant, kann dazu aber leider nichts sagen.

Außer eins vielleicht: Der Leistungsverlust hält sich für mich bestimmt im erträglichen Bereich: Kein neuer Computer hätte eine stärkere CPU bekommen als einen 2,8GHz Dualcore mit 45W TDP. Und so viel Leistung würden die auch nur deshalb haben, weil das die derzeit günstigsten Dualcores für AM3 Sockel sind.
Ich benötige nicht mehr Leistung, das einzige was mich derzeit an der CPU Entwicklung interessiert, ist die Verbesserung der Leistung/Watt und Senkung der TDP.
Ich kann mir auch vorstellen, dass es vielen so geht, auch Leuten die es noch gar nicht wissen. :)
Ich habe ja noch mind. zwei Monate Zeit mir darüber Gedanken zu machen. Vielleicht finde ich ja noch etwas heraus, ich werde es auf alle Fälle hier reinschreiben.

Darkstar

2011-01-01, 20:55:47

Ich würde auf den Einsatz von ECC-Ram verzichten. ECC-Ram ermöglicht es imho einem Hersteller unzuverlässige Module (zB. Test für die nonECC-Selektion nicht bestanden) auf entsprechenden Dimms zu recyceln. Wie möchtest du bei einem solchen Korrekturmechanismus noch feststellen, ob dir jemand instabilen Schrott angedreht hat? Auf so einem Modul könnten mehrere Bits komplett 'tot' sein - und du würdest für diesen Schrott genausoviel zahlen wie für ein Modul mit 100% einwandfreien Chips.Bei den SPARC-Servern von Sun ist es beispielsweise so, daß dort an das Betriebssystem gemeldet wird, wenn die ECC-Prüfung einen Fehler erkannt hat. Die laut Handbuch von Sun empfohlene Vorgehensweise ist dann, das entsprechende Speichermodul zu tauschen, falls der Fehler wiederholt auftritt. Keine Ahnung, ob bei x86ern die ECC-Fehlerkorrektur im Verborgenen arbeitet oder ob man diese Informationen auch transparent auslesen kann.

Bei PCs ohne ECC kann man erst recht nicht mit Sicherheit davon ausgehen, daß die Speichermodule immer zuverlässig arbeiten. Dummerweise hat man hier auch gar keine Möglichkeit, das im laufenden Betrieb zu überwachen. Man kann nur entweder den Memtest oder eine Nutzanwendung laufen lassen – nicht beides gleichzeitig.

Ich halte fehlerhaften Programmcode für den Hauptverursacher von System- und Programmabstürzen. Instabilitäten haben imho in den seltensten Fällen etwas mit kippenden Bits zu tun. (Es sei denn man weigert sich standhaft neuer Hardware mit memtest86+ auf den Zahn zu fühlen.)Dem stimme ich zu.

Gibt es inzwischen überhaupt einen Fall, indem ECC einen Programmabsturz verhindern konnte, der nicht in der selben Mikrosekunde auch von der Fehlerkorrektur des compilierten Codes abgefangen wird?Kompilierter Code hat normalerweise keine Fehlerkorrektur. Das einzige mir bekannte Betriebssystem, welches auf fehlerhaften Code (eingeschränkt) reagieren und z. B. generell fehlerhafte Treiber neu starten kann, ist Minix 3 (http://de.wikipedia.org/wiki/Minix_%28Betriebssystem%29#Minix_3). Unter Windows ist so etwas ähnliches nur bei den Grafiktreibern von NVIDIA und AMD möglich. Heutige Rechner arbeiten aus Anwendungssicht alle nach dem Prinzip der Von-Neumann-Architektur (http://de.wikipedia.org/wiki/Von-Neumann-Architektur), wo sowohl Programmbefehle als auch Daten im selben Speicher liegen. Je nachdem, wo das Bit kippt, können also Daten beeinflußt werden (ein Pixel im Film hat eine andere Farbe, in Excel kommt wird in einer Zelle ein anderer Wert angezeigt) oder der Programmablauf gestört werden (Sprungadresse wird verändert).

Bei der Verarbeitung von extrem großen Datenmengen mag ECC Vorteile haben, wenn man auf maximale Authentizität der Daten Wert legt.Das ist das Problem, nach Murphys Gesetz (http://de.wikipedia.org/wiki/Murphys_Gesetz) wird ein Bitfehler natürlich nur Deine wirklich wichtigen Daten treffen. :D

Zumal heutzutage auch viele Dateiformate (wie zB. .zip) ihre eigenen Korrektur-Algorithmen enthalten.ZIP hat keinen Korrektur-Algorithmus sondern auch nur CRC (http://en.wikipedia.org/wiki/Cyclic_redundancy_check) – vereinfacht gesagt, eine Art Parity-Prüfung. Damit können nicht alle Bitfehler korrigiert werden.

Möglicherweise gibt es bei sehr schnellem DDR3-Ram tatsächlich ein Problem mit kippenden Bits. Allerdings wären dann die anderen Korrekturmaßnahmen so gut, daß es bislang noch niemand bemerkt hat. Vielleicht würde die ECC-Korrektur sich positiv auf die Geschwindigkeit auswirken, wenn sie schneller wäre als die anderen Korrekturmaßnahmen. Aber das glaube ich erst, wenn ich es selbst gesehen hab.Es gibt keine „anderen Korrekturmaßnahmen“.

Meine Meinung: Ich halte ECC bei Dimms (auch im Serverbereich) für eine reine Beruhigungspille aus Zucker (die Wirkung ist rein psychologisch). Wenn ich mich nicht irre, gibt es sogar kein einziges i5/i7-Board (1156), welches ECC-Ram unterstützt. Nichtmal die richtig teuren:
http://www.mix-computer.de/html/product/detail.html?articleId=385189
Und die Boards funktionieren im großen und ganzen trotzdem. Wenn ich richtig informiert bin, werden die meisten neuen SandyBridge-CPUs ebenfalls ohne ECC-Unterstützung ausgeliefert (bis auf die richtig teuren). Es stellt sich also die Frage - WARUM geht man bei intel ein solches RISIKO ein (oder auch nicht). ;)Bisher war es immer so, daß die Server-Linie bei Intel „Xeon“ hieß und auch ECC unterstützte. Die von Dir genannten CPUs bzw. Chipsätze (i5/i7/SandyBridge) sind jedenfalls alle aus dem Desktopbereich.

Und zum Thema Risiko: Bei Intel ist man wohl der Meinung, daß ein zu Hause gekipptes Bit wohl eher Windows oder anderen Phänomenen angelastet wird. Bei dem berühmten FDIV-Bug (http://de.wikipedia.org/wiki/Pentium-FDIV-Bug#H.C3.A4ufigkeit_und_Auswirkungen_des_Fehlers) wollte man zuerst auch allen weismachen, daß kein Heimanwender davon betroffen ist.

Es kann natürlich sein, daß ECC im Serverbereich doch sinnvoll ist, weil dort gelegentlich 'recycelte'/'rundumerneuerte' Geräte zu absolut konkurrenzfähigen Preisen im Umlauf sind. Wer kann schon sagen wie ausgelutscht dort manche ECC-Module sind, die von Generation zu Generation weitervererbt wurden (wenn der Mann vom Service mal wieder in die große Restekiste gegriffen hat)?[/Sarkasmus]Wie schon oben erwähnt, sagt mir das bei richtigen Servern der Server selber. :)

PatkIllA

2011-01-01, 21:34:02

Kompilierter Code hat normalerweise keine Fehlerkorrektur. Das einzige mir bekannte Betriebssystem, welches auf fehlerhaften Code (eingeschränkt) reagieren und z. B. generell fehlerhafte Treiber neu starten kann, ist Minix 3 (http://de.wikipedia.org/wiki/Minix_%28Betriebssystem%29#Minix_3). Unter Windows ist so etwas ähnliches nur bei den Grafiktreibern von NVIDIA und AMD möglich. Heutige Rechner arbeiten aus Anwendungssicht alle nach dem Prinzip der Von-Neumann-Architektur (http://de.wikipedia.org/wiki/Von-Neumann-Architektur), wo sowohl Programmbefehle als auch Daten im selben Speicher liegen. Je nachdem, wo das Bit kippt, können also Daten beeinflußt werden (ein Pixel im Film hat eine andere Farbe, in Excel kommt wird in einer Zelle ein anderer Wert angezeigt) oder der Programmablauf gestört werden (Sprungadresse wird verändert).Wo ist denn bei dem Mimix 3 der Unterschied zu einem ganz normalen Watchdog? Wenn da ein Bit z.B. im Fehlermeldungstext kippt ist halt ein Buchstabe anders und das wars oder nicht?
Die heutigen Konsolen können veränderten Code zur Laufzeit erkennen.

Gast9t99

2011-01-01, 22:31:05

Bei den SPARC-Servern von Sun ist es beispielsweise so, daß dort an das Betriebssystem gemeldet wird, wenn die ECC-Prüfung einen Fehler erkannt hat. Die laut Handbuch von Sun empfohlene Vorgehensweise ist dann, das entsprechende Speichermodul zu tauschen, falls der Fehler wiederholt auftritt. Keine Ahnung, ob bei x86ern die ECC-Fehlerkorrektur im Verborgenen arbeitet oder ob man diese Informationen auch transparent auslesen kann.
Das ist tatsächlich ein Vorteil, da hierdurch bei einem Server eine Art Galgenfrist erkauft wird, bevor mit einem totalen Ausfall zu rechnen ist. Die Anzahl der Fehler, welche durch ECC in Folge ausgebügelt werden können, ist meine ich begrenzt. Auf der anderen Seite wäre es mir neu, daß ein Desktop PC mit Win7 oder meinethalben auch einem aktuellem Linux seinen User auffordert neuen Speicher zu kaufen, da ein ECC-Fehler aufgetreten ist.

Bei PCs ohne ECC kann man erst recht nicht mit Sicherheit davon ausgehen, daß die Speichermodule immer zuverlässig arbeiten. Dummerweise hat man hier auch gar keine Möglichkeit, das im laufenden Betrieb zu überwachen. Man kann nur entweder den Memtest oder eine Nutzanwendung laufen lassen – nicht beides gleichzeitig.
Ja - das ist richtig. Aber ich frage mich, ob der Verzicht auf Performance und die Mehrkosten für die Anschaffung von ECC-Ram im privaten Bereich gerechtfertigt sind. Sollten tatsächlich ECC-Fehler auftreten, wird der User ohnehin 'gezwungen' sein, neuen Speicher zu kaufen.

Kompilierter Code hat normalerweise keine Fehlerkorrektur. Es gibt keine „anderen Korrekturmaßnahmen“.
Da bin ich mir nicht so sicher. Viele Virenkiller und Kopierschutzsoftware machen es vor: Schon geringe Änderungen im Speicher werden augenblicklich erkannt und Anwendungen werden in Echtzeit beendet (ohne Systemabsturz).

Wie schon oben erwähnt, sagt mir das bei richtigen Servern der Server selber. :)
In diesem Fall wäre es im kommerziellen Bereich wie zB. einer Serverfarm sinnvoll. Man hat dann genug Zeit den Server runterzufahren und den Speicher auszutauschen. Ob so eine Früherkennung durch ECC im privaten Bereich sinnvoll ist? Wenn ich Dank ECC sehe, daß der Speicher kaputt ist, weil ein kleines Fenster aufpoppt wo drin steht: ECC-Fehler! - Dein Speicher ist kaputt, dann bin ich nicht wirklich besser dran, als wenn ich nach einem Bluescreen memtest starte und memtest mir sagt: Dein Speicher ist kaputt/das System ist instabil.

Gast

2011-01-01, 23:33:35

"The BIOS in some computers, and operating systems such as Linux, allow counting of detected and corrected memory errors, in part to help identify failing memory modules before the problem becomes catastrophic."

aus http://en.wikipedia.org/wiki/Dynamic_random_access_memory

Bei mir läuft auf jeder Maschine Linux, außer auf dem Router... :)

Gast

2011-01-01, 23:36:08

"This translates in most cases to a real world decrease in performance of approximately 2-3%."

Quelle:
http://www.pcguide.com/ref/ram/errECC-c.html

Darkstar

2011-01-02, 00:13:01

Wo ist denn bei dem Mimix 3 der Unterschied zu einem ganz normalen Watchdog?Wie Minix funktioniert, weiß ich auch nicht, aber vermutlich wird es da auch keine außergewöhnlichen Techniken geben – sprich, man setzt Watchdogs ein. Der Vorteil von Minix gegenüber Windows ist halt, daß hier, wenn ein Treiber Amok läuft, kein Bluescreen kommt und man den Rechner sofort neustarten muß und ggf. Arbeit in offenen Anwendungen verliert.Wenn da ein Bit z.B. im Fehlermeldungstext kippt ist halt ein Buchstabe anders und das wars oder nicht?Ich vermute, es wird nur darauf geachtet, ob ein Treiber sich nicht normal verhält (also keine komplette Konsistenzprüfung durch Minix, die auch die Fehlertexte einschließen würde).Die heutigen Konsolen können veränderten Code zur Laufzeit erkennen.Das bezieht sich sicherlich auf den Kopierschutz. Bei einer Konsole läuft allerdings immer nur eine Anwendung auf einmal. Deshalb ist es hier kein so großes Problem, wenn mal ein Bit kippt und die Anwendung das bemerkt und die weitere Ausführung verweigert. Man startet neu und kann weiterspielen. Ja, ist halt blöd, wenn man nur noch einen Treffer gebraucht hätte, um den Endgegner zu besiegen oder der letzte Spielstand defekt ist. Aber es gehen keine sonstigen kritischen Daten verloren.

Da bin ich mir nicht so sicher. Viele Virenkiller und Kopierschutzsoftware machen es vor: Schon geringe Änderungen im Speicher werden augenblicklich erkannt und Anwendungen werden in Echtzeit beendet (ohne Systemabsturz).Das kostet erheblich mehr Performance als die ECC-Hardwarelösung. Ich bin mir auch nicht sicher, daß damit alle Speicherbereiche abgedeckt werden können. Außerdem ist die Hardwarelösung doch um einiges robuster (weil einfacher gestrickt).
In diesem Fall wäre es im kommerziellen Bereich wie zB. einer Serverfarm sinnvoll. Man hat dann genug Zeit den Server runterzufahren und den Speicher auszutauschen. Ob so eine Früherkennung durch ECC im privaten Bereich sinnvoll ist? Wenn ich Dank ECC sehe, daß der Speicher kaputt ist, weil ein kleines Fenster aufpoppt wo drin steht: ECC-Fehler! - Dein Speicher ist kaputt, dann bin ich nicht wirklich besser dran, als wenn ich nach einem Bluescreen memtest starte und memtest mir sagt: Dein Speicher ist kaputt/das System ist instabil.Es geht ja nicht nur um die Erkennung, sondern eben auch um die Korrektur.

Zum einen ist die ECC-Prüfung ähnlich wie die S.M.A.R.T.-Prüfung bei Festplatten. Sie verrichtet im Hintergrund unauffällig ihren Dienst, interessierte Leute können zuvor schon schauen, ob sich was anbahnt (ich hoffe mal, mit entsprechenden Tools kann man das wie bei S.M.A.R.T. irgendwie auslesen – das BIOS sollte sowas auf alle Fälle sammeln) und wenn ein richtiger Defekt kommt, ist das Gerät einfach nur kaputt, ob mit oder ohne ECC/S.M.A.R.T.

Zum anderen hilft ECC optimal gerade in solchen Fällen, wo es darauf ankommt: Wenn das Bit unbemerkt in einem Bereich mit wichtigen Daten kippt. Ein Absturz wäre ja noch als gut zu bewerten, da bekommt man sofort mit, daß etwas nicht stimmt. Aber wenn Daten korrumpiert werden, dann ist das übel, weil man es meist erst viel später feststellt. Man stelle sich nur vor, beim Onlinebanking oder bei der elektronischen Steuererklärung wird eine Zahl in einem Eingabefeld beim Absenden/Abspeichern verändert. Heutzutage werden Privat-PCs schließlich immer häufiger auch für kritische Anwendungen eingesetzt.

"The BIOS in some computers, and operating systems such as Linux, allow counting of detected and corrected memory errors, in part to help identify failing memory modules before the problem becomes catastrophic."

aus http://en.wikipedia.org/wiki/Dynamic_random_access_memory

Bei mir läuft auf jeder Maschine Linux, außer auf dem Router... :)Solaris kann übrigens zusätzlich zum Erkennen und Korrigieren von Speicherfehlern Speicherzellen, bei denen Defekte gehäuft auftreten, markieren und vom zukünftigen Gebrauch ausschließen. :)

In dem ECC-Abschnitt aus dem Wikipedia-DRAM-Link (http://en.wikipedia.org/wiki/Dynamic_random_access_memory#Errors_and_error_correction) gibt es am Ende übrigens noch ein paar Zahlen zur Häufigkeit des Auftretens von Bitfehlern (von zehn hoch minus zehn bis zehn hoch minus siebzehn Fehler pro Bit mal Stunde):
Recent tests give widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.

Ob einem nun ECC die Zusatzkosten und den leichten Performanceverlust wert sind, kann jeder selbst entscheiden. Es ist halt wie der Abschluß einer Zusatzversicherung. :)

airbag

2011-01-02, 00:35:35

Gast9t99

2011-01-02, 04:32:50

"The BIOS in some computers, and operating systems such as Linux, allow counting of detected and corrected memory errors, in part to help identify failing memory modules before the problem becomes catastrophic."
Also wenn ECC im Desktopbereich wirklich so toll wäre, hätte sich das längst rumgesprochen. Stattdessen ist es im BIOS per default deaktiviert und muß erst explizit angeschaltet werden. Was also bringt ECC?

Mehr Performance? - Nein, im Gegenteil.
Weniger Stromverbrauch? - Nein, im Gegenteil (1 Chip mehr pro Modul).
Mehr Flexibiltät bei den Timings? - Nein.
Weniger Kosten bei der Anschaffung? - Nein, im Gegenteil.
Mehr Stabilität? - Ja - aber nur für die Zeitspanne zwischen den ersten Fehlern bis zum Totalausfall des gesamten Moduls.

Wenn ich jetzt abwägen müßte, dann wären das auf der contra-Seite eine Menge saure Zitronen.

Und was auch noch zu klären wäre ist, was passiert eigentlich wenn das schwache Bit ausgerechnet in dem Chip zuerst auftritt, der eigentlich die korrekte Checksum liefern soll? Totalschaden? Von echter Ausfallsicherheit kann also auch im Serverbereich schonmal nicht die Rede sein. Das Ausfallrisiko wird bestenfalls vermindert. Bei Fehlern, die alle Chips des Moduls betreffen, ist ECC dann auch keine Option. Ich denke da zB. an Fehler/Instabiltät durch falsche Timings oder zu hoch/zu gering gewählte Spannung oder ähnliches, da hiervon alle Speicherchips (auch der Chip mit der Checksum) betroffen wären.

Wenn der ECC-Chip wenigstens besonders ausfallsicher wäre - aber davon steht nix im Kleingedruckten. Wie man hier sieht, ist ein ECC-Modul tatsächlich nur 8+1 Chips:
http://www.mix-computer.de/html/product/detail.html?articleId=284921
Statt 8 Chips von mäßiger Qualität und von denen einer potentiell versagt, hätte man dann eben 9 Chips, von denen einer versagt. Und wehe, es ist der falsche...
;)

Wenn etwas auf verschiedene Arten schiefgehen kann, dann geht es immer auf die Art schief, die am meisten Schaden verursacht.

Coda

2011-01-02, 18:48:19

Mehr Stabilität? - Ja - aber nur für die Zeitspanne zwischen den ersten Fehlern bis zum Totalausfall des gesamten Moduls.
Das ist totale Grütze. Einzelne Bitfehler werden vor allem durch kosmische Strahlung verursacht, bzw. es sind einzelne Zellen defekt. Daraus auf einen unabwendbaren kommenden Totalausfall eines Moduls zu schließen ist schon sehr weit hergeholt. Du gehst von einer völlig falschen Problemstellung aus, die ECC überhaupt nicht abdeckt.

Für denjenigen, der Speicher braucht, der auch ganze Chipausfälle verträgt gibt es Chipkill-Speicher von IBM. Das ist aber nur für ultrakritische Systeme überhaupt relevant.

Es hat seinen guten Grund warum in Servern und Supercomputern fast ausschließlich ECC zum Einsatz kommt. Wenn man keine Prüfzyklen laufen lässt sondern nur bei Reads prüft geht auch keine Performance verloren.

Genau das dargestellte Verfahren wird genutzt.

Das Verfahren nennt sich Hamming-Code (http://de.wikipedia.org/wiki/Hamming-Code).
Nein, es wird kein Hamming verwendet. Es sind eher reduzierte Reed-Salomon-Codes. Es ist aber implementierungsspezifisch was der Speichercontroller mit den zusätzlichen Bits macht. Die zusätzlichen 8 Bit reichen aber für 1 bit Fehlerkorrektur und 2 bit Fehlererkennung (nach Hamming-Abstand).

S940

2011-01-02, 22:30:20

Ich würde auf den Einsatz von ECC-Ram verzichten. ECC-Ram ermöglicht es imho einem Hersteller unzuverlässige Module (zB. Test für die nonECC-Selektion nicht bestanden) auf entsprechenden Dimms zu recyceln.
Wo hast Du das den her ? Da hast Du was grundlegend falsch verstanden. Es werden die gleichen Chips verbaut. Wenn Du bei neuen ECC DIMMs ins Log schaust und da massenhaft Errors drinstehen, dann ist das ein Reklamationsgrund.

Abgesehen davon ist das kein sinnloses Thema. ECC und Parity gibts im Serverbereich seit Jahrzehnten und jetzt kommst Du daher und meinst alles sei nutzlos ... ja ne klar ... :freak:

Das Thema wird mit steigendem RAM Ausbau immer wichtiger, auch die ganze RAM Übertakterei senkt ganz sicher nicht die Fehlerwahrscheinlichkeit.

Ein PCGH Redakteur meinte kürzlich im Sandy Thread, dass RAM OC nutzlos ist, das sieht später bei Bulldozer sicherlich ähnlich aus. Von daher ist jedes Investment in ECC RAM sinnvoller als in gepimptes OC RAM. Billiger ist es ohnehin und die +10 Euro gegenüber non-ECC RAM ist mir die Zusatzsicherheit allemal wert :)
Das ist totale Grütze. Einzelne Bitfehler werden vor allem durch kosmische Strahlung verursacht, bzw. es sind einzelne Zellen defekt. Daraus auf einen unabwendbaren kommenden Totalausfall eines Moduls zu schließen ist schon sehr weit hergeholt. Du gehst von einer völlig falschen Problemstellung aus, die ECC überhaupt nicht abdeckt.
Na - selbst wenns so wäre, wie er annimmt, dass man "nur" nen Vorteil hätte bevor ein RAM Module den Geist aufgibt, dann sähe ich das auch als Vorteil. Immerhin weiss man dann dank ECC, dass es am RAM liegt. Damit spart man sich die ganze Fehlersuche wenn ein PC einmal instabil läuft. Das gilt auch im gegensätzlichen Fall, dann wenn der PC Mucken macht, aber nicht der RAM schuld ist.

Gast

2011-01-02, 22:33:33

Kann Sandy Bridge denn mit ECC-Ram auf allen Chipsätzen umgehen?
Bei AMD ist dies ja AFAIK schon länger Standard.

S940

2011-01-02, 22:35:51

Kann Sandy Bridge denn mit ECC-Ram auf allen Chipsätzen umgehen?
Bei AMD ist dies ja AFAIK schon länger Standard.
Intel deaktiviert das meistens bei den Desktop Versionen. Sollte sich dann zwar leicht umschiffen lassen, indem man sich nen Sockel 1155 Xeon kauft, für 1156 gabs die ja auch.

Aaaber dann greift wieder das Problem, dass auch bei AMD der Fall ist: Das Mainboard BIOS muss es aktivieren können...
Keine Ahnung, welches BIOS das kann, eventuell wie bei AMD Asus .. keine Ahnung. Falls die Xeons in der CPU Kompatibilitätsliste stehen, sollte man es erwarten dürfen.

Gast

2011-01-02, 23:36:01

Ja man muss wirklich sorgfältigst prüfen, was man für Hardware kauft, wirklich aufs genaueste.
Ich habe ins Handbuch des ASUS M4A89GTD Pro (AMD 890GX Chipsatz) geguckt, dort kann man sogar mehrere Parameter bezüglich des ECC Systems verändern. Eine gute Unterstützung ist also scheinbar gegeben.
Mich hat eben diese Tatsache sehr erfreut: Servertechnik in Desktopcomputern (oder sagen wir mal Heimcomputern) hat mich schon immer fasziniert.
Als RAID vor Jahren nur durch teure Controller realisiert werden konnte, habe ich mir diese geholt und mich geärgert, dass schon zwei Festplatten den PCI Bus auslasteten.
Wenn ich also sehe, dass eine solche Technik jetzt in einem modernen für mich erschwinglichen Mainboard eingebaut ist, verwende ich sie gerne.

Coda

2011-01-03, 13:14:50

Die meisten (alle?) ASUS-AMD-Boards können ECC. Das ist wirklich sehr erfreulich.

Spasstiger

2011-01-03, 17:19:02

Sind ECC-DIMMs nicht immer mit 72 Datenleitungen angebunden? Dann müsste ja jeder Hersteller von AM3- oder 1155/1156-Boards die 8 zusätzlichen Datenleitungen immer vom DIMM-Slot zum CPU-Sockel routen. Lohnt das, wenn die breite Masse gar kein ECC nutzt? Gerade bei Sockel 1155/1156, wo nur die Xeon-Varianten unterstützt werden, würde mich das wundern.

Coda

2011-01-03, 20:32:49

Natürlich ist das so. Deshalb unterstützen ja auch viele Boards eben kein ECC. Muss man genau danach schauen.

Exec

2011-01-03, 21:20:01

Ich hab für mein Phenom II System auch 16GB unbuffered ECC geholt. ECC gab bei mir den Ausschlag für AMD gegenüber Intel, da selbst die günstigen Xeon Systeme unverhältnismässig teurer sind. Bei AMD bekommt man ECC ja quasi umsonst dazu.. wär ja blöd darauf zu verzichten wegen dem mickrigen Performance Unterschied.

Intel hatte ja schon versucht ECC zu verbreiten (Rambus) ist aber am Preis gescheitert und Microsoft hatte in seinen Empfehlungen zu Windows Vista ja zuerst auch ECC empfohlen ist dann aber aber später zurück gerudert.

Coda

2011-01-03, 22:36:51

Was hat Rambus mit ECC zu tun? Da gab's auch RIMMs mit und ohne.

Ric

2011-01-03, 22:48:28

Ja, anfangs mit 16Bit (extern) ohne ECC, 18 (extern) mit ECC.

Exec

2011-01-04, 00:11:58

Was hat Rambus mit ECC zu tun? Da gab's auch RIMMs mit und ohne.

Dann hab ich wohl fälschlicherweise angenommen, dass bei den Preisen ECC Standard gewesen wäre ;)

Tesseract

2011-01-04, 01:07:42

Und was auch noch zu klären wäre ist, was passiert eigentlich wenn das schwache Bit ausgerechnet in dem Chip zuerst auftritt, der eigentlich die korrekte Checksum liefern soll?
dann erkennt die paritätsprüfung einen fehler, was denn sonst?
die frage ist nicht welche bits umfallen, sondern wieviele bits (eines atomaren codeblocks) gleichzeitig umfallen. je nach dem ist der fehler dann korrigierbar, nur erkennbar oder in einem worst case fehlerhaft aber unerkennbar. die chance auf gemeinsames eintreten ist allerdings unglaublich gering weil exponentiell kleiner als vom einzelereignis. deswegen kann eine paritätsprüfung durchaus den unterschied ausmachen, ob du statistisch einen nicht erkennbaren fehler pro woche oder einen in ein paar millionen jahren hättest.

GloomY

2011-01-05, 17:53:40

Und was auch noch zu klären wäre ist, was passiert eigentlich wenn das schwache Bit ausgerechnet in dem Chip zuerst auftritt, der eigentlich die korrekte Checksum liefern soll? Totalschaden? Von echter Ausfallsicherheit kann also auch im Serverbereich schonmal nicht die Rede sein.Anscheinend hast du keine Ahnung wie ECC bzw. Hamming-Codes funktionieren. Vielleicht solltest du dich erstmal damit beschäftigen, bevor du hier so viel FUD verbreitest.

Das ECC-Verfahren kann selbstverständlich einen beliebigen Bitfehler in einem 72-Bit großen Wert (64-Bit Daten und 8-Bit ECC) erkennen und korrigieren, also auch in den 8-Bit ECC-Daten! Das ist ja gerade der Clou an den Hamming-Codes!

Um genau zu sein, kann man mit dem Verfahren zwei beliebige Bitfehler erkennen (jedoch dann nicht mehr korrigieren, d.h. das falsche Bit berechnen und somit den ursprünglichen Wert wiederherstellen). Einen beliebigen Bitfehler (pro 72-bit) kann man eben sowohl erkennen als auch wieder beheben. Im Englischen spricht man deswegen auch kurz von: "single-correct, double-detect".

Ich schlag' dir mal folgendes vor (hab' ich selbst schon während meines Studiums gemacht): Nimm' dir ein Blatt Papier und schreibe eine beliebige 64 bit lange Zahl drauf. Dann rechne dafür den ECC Wert aus. Von den resultierenden 72 bit nimmst du dir ein beliebiges, und drehst es um. Dann gehst du zu einem Kumpel, der das gleiche gemacht hat, ohne dass einer von euch die Berechnung des anderen gesehen habt. Dann tauscht ihr die Zahlen aus und jeder rechnet aus der neu erhaltenen 72-bit Zahl die Stelle aus, an der das eine Bit falsch ist (was der andere vorher umgedreht hat). Dann dreht ihr dieses Bit nochmals um, um wieder die original 64 bzw. 72 bit zu bekommen und fragt den anderen ob das die richtige Stelle war. Wenn ihr es beide richtig macht, habt ihr erfolgreich ECC-Korrektur auf dem Papier gemacht.

Statt 8 Chips von mäßiger Qualität und von denen einer potentiell versagt, hätte man dann eben 9 Chips, von denen einer versagt. Und wehe, es ist der falsche...
;)Die Annahme, dass qualititiv schlechtere Chip bei ECC verbaut werden, ist absoluter Quatsch! Ganz im Gegenteil: Mit ECC kann man nun tatsächlich Fehler erkennen (und das dem OS melden). D.h. man hat kann nun tatsächlich quantitativ festhalten, wie gut oder wie schlecht ein Speichermodul ist. Ohne ECC merkst du die Modulfehler gar nicht und die Hersteller können allen möglichen (qualitativen) Mist verbauen (was sie auch teilweise tun). Daher würde ich sogar so weit gehen und behaupten, dass qualitativ bessere Chips für ECC verwendet werden! Wie gesagt: ECC-Fehler sind ein Rückgabegrund bei Speicher.

edit: Und Performance sollte es nur kosten, wenn der Memory-Scrubber aktiviert ist. Ansonsten sollte es keine Verzögerung geben, wenn es gut implementiert ist.

Gast9t99

2011-01-05, 20:01:57

Anscheinend hast du keine Ahnung wie ECC bzw. Hamming-Codes funktionieren. Vielleicht solltest du dich erstmal damit beschäftigen, bevor du hier so viel FUD verbreitest.
Vielen Dank Für diesen Unverschämt hilfreichen Hinweis.

Das ECC-Verfahren kann selbstverständlich einen beliebigen Bitfehler in einem 72-Bit großen Wert (64-Bit Daten und 8-Bit ECC) erkennen und korrigieren, also auch in den 8-Bit ECC-Daten! Das ist ja gerade der Clou an den Hamming-Codes! Um genau zu sein, kann man mit dem Verfahren zwei beliebige Bitfehler erkennen (jedoch dann nicht mehr korrigieren, d.h. das falsche Bit berechnen und somit den ursprünglichen Wert wiederherstellen). Einen beliebigen Bitfehler (pro 72-bit) kann man eben sowohl erkennen als auch wieder beheben. Im Englischen spricht man deswegen auch kurz von: "single-correct, double-detect".
Das ist nur ein weiteres Argument gegen ECC. Ich glaube nicht, daß sich der TS über die tatsächliche Leistungsfähigkeit von ECC im klaren ist. Aber schön, daß jemand mal die Grenzen von ECC aufgezeigt hat, der nicht offensichtlich aus dem Bereich Marketing für Serverkunden stammt.

Ich schlag' dir mal folgendes vor (hab' ich selbst schon während meines Studiums gemacht): Nimm' dir ein Blatt Papier (..)
Und ich schlag dir folgendes vor: Behandel andere Leute nicht wie Idioten. Ich habe nicht behauptet, daß ich mich mit dem ECC-Verfahren auskenne. Daher war meine Frage ernst gemeint: Was passiert, wenn das fehlerhafte Bit im ECC-Chip auftritt. Deine Antwort auf meine Frage ist im Ergebnis zwar richtig, aber die Begründung ist absolut mangelhaft. Für diejenigen, die (so wie ich) keinen Bock haben, sich mal mit einem Blatt Papier hinzusetzen und bei 'Papa Schlumpf' irgendwelche rein hypothetischen Rechenexperimente mit zudem höchst zweifelhaftem Ausgang zu veranstalten (dein Vertrauen in meine mathematischen Fähigkeiten ehrt mich - aber ich kann nur davor warnen, von mir abzuschreiben), ein Link zum Hamming-Verfahren:

Each check bit has a corresponding check equation that covers a portion of all the bits, but always includes the check bit itself.
http://www.cs.utsa.edu/~wagner/laws/hamming.html

Die Annahme, dass qualititiv schlechtere Chip bei ECC verbaut werden, ist absoluter Quatsch!
Schön das es dich gibt. Die Idee, daß Hersteller ihre Chips selektieren und anschließend mit unterschiedlichen Preisschildchen versehen, ist natürlich völlig fernliegend. Wenn ich als Hersteller von Ram-Modulen zwei Bauformen (mit und ohne ECC) hätte, würde ich mir natürlich keine Gedanken darüber machen, welche Chips ich auf auf welches Modul packe. Wozu auch? Ich habe bei mir im Einkauf ja zwei Zauberer sitzen, die es schaffen, daß inzwischen ein ECC-Modul mit 9 Chips zum selben Preis verkauft werden kann, wie ein Modul mit 8 Chips. Wie das kommt? - Pure Magie! :naughty:
Mit Memtest86+ krieg ich bei Modulen ohne ECC direkt die rote Karte. Darum werde ich als Hersteller natürlich darauf achten, daß besonders die Module mit Korrekturfunktion nur mit den teureren Chips bestückt werden. Denn nur so ist gewährleistet, daß sie nahezu zum gleichen Preis wie non-ECC-Module in den Handel gelangen. [/Ironie]

Ganz im Gegenteil: Mit ECC kann man nun tatsächlich Fehler erkennen (und das dem OS melden). D.h. man hat kann nun tatsächlich quantitativ festhalten, wie gut oder wie schlecht ein Speichermodul ist.
Ach wirklich. Und du meinst, daß sich der 0815-User darüber im klaren ist, was ihm der ECC-Count sagt? Oder was ein permanent auftretender ECC-Fehler wirklich bedeutet? Ich glaube es würde sogar einige geben, die sich über das Auftreten eines ECC-Fehlers freuen: 'Schau an! - Hab ich damals doch den richtigen Ram gekauft!'.
:facepalm:
Und JA! es gibt sie noch: Ram-Module, die einfach mal funktionieren... ganz ohne Hokuspokus. Und von diesen sollen es sogar eine Menge sein (nicht jeder betreibt seinen Ram außerhalb der Specs).

Ohne ECC merkst du die Modulfehler gar nicht und die Hersteller können allen möglichen (qualitativen) Mist verbauen (was sie auch teilweise tun).
Wenn man die Fehler ohne den ECC-Check nicht bemerken würde, dann frage ich mich: Wozu dann ECC? Ist ECC reiner Selbstzweck? Nebenbei: Speicherfehler(Modulfehler) werden sehr wohl auch ohne ECC erkannt. Das ist ja das schöne ...und offenbar auch der Grund, warum einige Leute (wie zB. auch der TS) laut darüber nachdenken, ob sie sich ECC-Speicher zulegen sollten.

Daher wäre es recht interessant, ob du unter diesem Aspekt auch nochmal was zum Thema dieses Threads sagen könntest:
ECC Speicher sinnvoll?
Wozu der TS ECC haben möchte, hat er ja oben dargelegt.

Daher würde ich sogar so weit gehen und behaupten, dass qualitativ bessere Chips für ECC verwendet werden! Wie gesagt: ECC-Fehler sind ein Rückgabegrund bei Speicher.
Sorry - aber bei dem, was du dir da gerade zurechtlegst, kann ich nur noch staunen. Hast du in deinem Leben jemals versucht bei einem Händler ein ECC-Modul zurückzugeben, welches Dank ECC einen Fehler nachweist, der sich aber Dank ECC nicht auswirkt? Ein Modul also, welches voll funktionsfähig ist im Sinne des Kleingedruckten?

edit: Und Performance sollte es nur kosten, wenn der Memory-Scrubber aktiviert ist. Ansonsten sollte es keine Verzögerung geben, wenn es gut implementiert ist.
Die ECC-Korrektur muss(?) durch die CPU erfolgen. Es wäre mir jedenfalls neu, daß ECC-Ram den Fehler gleich selbst korrigiert. ECC-Ram liefert nur eine erweiterte Bitfolge ab, die dann nachträglich durch einen Algorithmus interpretiert werden kann. Dieser Algorithmus kostet Performance. Und da er bei jedem Speicherzugriff (quasi mit jedem Takt) auftritt, wäre es ungemein interessant mal zu erfahren, wieviel Performance tatsächlich auf der Strecke bleibt. Auch wäre es interessant zu erfahren, wo diese zusätzlichen 8 ECC-Bit generiert werden. Ich habe den 'dringenden Verdacht', daß dies ebenfalls die CPU übernehmen muss. Ein zusätzlicher Controllerchip, der diese Aufgaben erledigen könnte, ist auf dem oben von mir verlinkten Foto eines ECC-Moduls nicht zu erkennen.

Hättest du den Thread aufmerksamer gelesen, dann wäre dir auch nicht entgangen, daß es bereits CPUs gab und gibt, bei denen sich über das BIOS ein ECC-Algorithmus für den Level 2/ Level3 -Cache aktivieren ließ. Der hierdurch verursachte Performanceverlust war (wenn man den Berichten im Netz glaubt) mehr als deutlich. Hätte man besser implentieren können/müssen sagst du. Hmm... ich seh das eher pessimistisch und glaube, daß die Leute, die das damals 'verbrochen' haben, schon ziemlich gut waren in ihrem Fach.

Gast

2011-01-05, 23:39:44

Gast9t99, es ist ja schön, wenn du versuchst mir zu helfen. Anfangs habe ich deine "kritischen" Antworten auch noch ernst genommen.

Jetzt kommen mir allerdings doch einige Zweifel:

"Ach wirklich. Und du meinst, daß sich der 0815-User darüber im klaren ist, was ihm der ECC-Count sagt?"
Keiner der hier antwortenden Leute ist ein 0815 User, mich eingeschlossen. Meine Frage war auch keine Frage die ich im ARD Buffet hätte stellen können... Ich denke du weißt was ich meine.

"Ich glaube es würde sogar einige geben, die sich über das Auftreten eines ECC-Fehlers freuen: 'Schau an! - Hab ich damals doch den richtigen Ram gekauft!"

Wenn der Fehler nach mehreren Jahren auftritt: Ja ich würde mich freuen, am besten wäre es, wenn der Fehler noch in der Garantiezeit auftritt. Dann kann ich das Modul ohne hohe Zusatzkosten austauschen.

Deine Anmerkung zu Gloomys "Ohne ECC merkst du die Modulfehler gar nicht und die Hersteller können allen möglichen (qualitativen) Mist verbauen (was sie auch teilweise tun)."

NATÜRLICH "merkt" man es nicht, außer das System stürzt ab. Aber das ist ja das tückische! Ich will keine Daten haben, die angeblich erfolgreich geschrieben wurde, aber Fehler enthalten. DARUM geht es doch!

"Sorry - aber bei dem, was du dir da gerade zurechtlegst, kann ich nur noch staunen. Hast du in deinem Leben jemals versucht bei einem Händler ein ECC-Modul zurückzugeben, welches Dank ECC einen Fehler nachweist, der sich aber Dank ECC nicht auswirkt? Ein Modul also, welches voll funktionsfähig ist im Sinne des Kleingedruckten?"

Ich gehe sehr stark davon aus, dass ich ein Austauschmodul bekomme. Ich werde diesbezüglich bei einem Händler nachfragen. Ich bin mir der positiven Antwort sicher!

Zur Performance:

Wenn DU den Thread aufmerksam gelesen hättest, wärst du über meine Links gestolpert. Mindestens einer zeigt auf, dass sicher der Leistungsverlust stark in Grenzen hält.
Es gibt außerdem Unterschiede zwischen ECC im L2/L3 Cache und ECC im RAM: Zwischen der Speicherkapazität liegen Größenordnungen, woraus folgt, dass die Ausfallwahrscheinlichkeit beim RAM deutlich (deutlich) größer ist. Der Leistungsverlust beim L2 ECC dürfte daher rühren, dass auf diesen sehr viel öfter zugegriffen wird.
Und nochmal frage ich mich: Juckt es mich, selbst wenn meine neue CPU 10% langsamer ist, als sie ohne alle Korrekturmechanismen wäre? Mich nicht. Und in nem Gamersystem, des nix kosten soll, viel Leistung bringen soll damit ich lustige Egoshooter spielen kann, da würds mich auch nicht interessieren, ob ein Bit umkippt oder zwei oder drei. Hauptsache der Highscore stimmt. Ich habe aber kein Gamersystem, ich habe deutlich andere Anforderungen!

Gast9t99

2011-01-06, 05:27:20

Gast9t99, es ist ja schön, wenn du versuchst mir zu helfen. Anfangs habe ich deine "kritischen" Antworten auch noch ernst genommen.
Wirklich?

Keiner der hier antwortenden Leute ist ein 0815 User, mich eingeschlossen.
Dem stimme ich nicht zu.

Wenn der Fehler (..) auftritt: Ja ich würde mich freuen, am besten wäre es, wenn der Fehler noch in der Garantiezeit auftritt.
Genau diesen gedanklichen Schritt hatte ich vorhergeahnt. Kommt dir diese Einstellung nicht selbst wenigstens ein kleines bischen 'merkwürdig' vor? Man müßte wahrscheinlich Psychologie studiert haben, um diesen Thread vollständig auskosten zu können. :uponder:

NATÜRLICH "merkt" man es nicht, außer das System stürzt ab.
Du glaubst im Ernst, daß man einen Speicherdefekt bei Inbetriebnahme des PCs nicht auch mit Memtest86+ erkennen würde, bzw. daß es überflüssig ist den Arbeitsspeicher ab und an mal mit so einem Tool zu überprüfen?

Aber das ist ja das tückische! Ich will keine Daten haben, die angeblich erfolgreich geschrieben wurde, aber Fehler enthalten. DARUM geht es doch!
Und gerade dazu ist ECC imho eher nicht geeignet. ECC bei Arbeitsspeicher ist ein Algorithmus mit dem versucht wird ein Serversystem stabil zu halten und Systemabstürze zu vermeiden. Auch mit ECC wird von 2 falschen Bits nur 1 korrigiert. (Das hatte ich mir auch anders vorgestellt. - Man lernt nie aus.) Fehler in Daten entstehen imho überwiegend nicht durch kippende Bits im Arbeitsspeicher, sondern an anderer Stelle.

Ich gehe sehr stark davon aus, dass ich ein Austauschmodul bekomme. Ich werde diesbezüglich bei einem Händler nachfragen. Ich bin mir der positiven Antwort sicher!
Das läßt du dir dann am besten vor dem Kauf nochmal schriftlich geben. Die Personen, die in erster Linie mit dem Verkauf betraut sind, sind manchmal nicht so gut in Detailfragen der Gewährleistung/Garantie eingearbeitet, wie das Personal in der Reklamationsabteilung. Humor ist, wenn man trotzdem lacht.

Es gibt außerdem Unterschiede zwischen ECC im L2/L3 Cache und ECC im RAM: Zwischen der Speicherkapazität liegen Größenordnungen, woraus folgt, dass die Ausfallwahrscheinlichkeit beim RAM deutlich (deutlich) größer ist.
Interessanter Gedanke - leider völlig irrelevant. Zum einen ist ein Speicherfehler infolge von Degradation innerhalb einer CPU (L2Cache) deutlich wahrscheinlicher als im Arbeitsspeicher und zum anderen: Die Kapazität eines Chips spielt imho überhaupt keine Rolle für die Wahrscheinlichkeit einer defekten Speicherzelle. In erster Linie ist die Fertigungsqualität des Chips maßgeblich. Nach deiner Theorie müßte der Yield bei 'Speichkapazitäten in deutlichen Größenordnungen' ja unglaublich hoch sein. Ist er aber nicht. Das liegt auch daran, daß Fehler im Chip bereits bei der Herstellung durch redundante Schaltungen ausgeglichen werden. Chips mit vielen Fehlern/redundanten Schaltungen werden selektiert. Und meine Befürchtung ist, daß es gerade diese Gruppe von Chips ist, die ihr neues zuhause bevorzugt auf ECC-Modulen mancher Hersteller findet. Meine Überlegung in diesem Zusammenhang ist, daß sich die neuerdings niedrigen Preise für ECC-Module .... aber das interessiert dich ja sowieso nicht.

Der Leistungsverlust beim L2 ECC dürfte daher rühren, dass auf diesen sehr viel öfter zugegriffen wird.
Reine Spekulation. Dem könnte man entgegenhalten, daß der L2-Cache ganz anders angebunden ist, als der Arbeitsspeicher.

Und nochmal frage ich mich: Juckt es mich
Manche Stellen fangen erst dann an zu jucken, wenn man dran denkt. Also frag dich nicht zu oft.... irgendwann juckts wirklich.

Und in nem Gamersystem, des nix kosten soll (..) ich habe deutlich andere Anforderungen!
Ich drück dir die Daumen, daß du für dich die richtige Wahrheit findest. Es gibt viele Gamersysteme, die später ihren Lebensabend als zuverlässige Fileserver in irgendwelchen staubigen Kellern verbringen. Den umgekehrten Fall, wo ein ehemals wirklich teures Serversystem selbst als 'Gamersystem des nix kosten soll' im Kinderzimmer gelandet ist, gabs meines Wissens noch nie. Man möchte fast neugierig werden, was für unglaublich sensible Daten es sind, die durch alle erdenklichen Maßnahmen geschützt werden sollen. Und warum hierfür nicht ein richtiges Serversystem (mit ECC und allem drum und dran) angeschafft wird, sondern im Hobbykeller was eigenes zusammengebastelt wird.... Freiberufler und kein Geld wär mein Tip.

Zum Schluß möchte ich dir noch ein paar Gedanken mit auf den Weg geben:
Was macht dich glauben, daß ein Fehler durch Degradation bei deinem Arbeitsspeicher früher auftritt, als ein Fehler durch Degradation bei deiner CPU? Die geringere Anzahl von Schaltungen? Die deutlich geringere Leistungsaufnahme oder die Temperatur des Arbeitsspeichers? Meinst du das deine Daten in der CPU sicherer aufgehoben sind, als im Arbeitsspeicher? Jetzt denkst du vielleicht, du würdest es ja schließlich sofort merken, wenn die CPU einen Fehler hätte. - Und richtig: Die Wahrscheinlichkeit ist ausgesprochen hoch, daß du es sofort merken würdest. Und zwar meiner Meinung nach nahezu genauso hoch wie bei einem kaputten Arbeitsspeicher. Der Ram wird zwar nicht mehr -wie bei PCs aus dem letzten Jahrtausend- beim Start 3x 'hochgezählt', das bedeutet imho aber nicht, daß er überhaupt nicht geprüft wird. Falls du vorhast ein zuverlässiges 24/7-System zu bauen (immer an), dann wirst du noch ganz andere Probleme mit StandardPC-Komponenten bekommen.

PS: Es ist mir wirklich vollkommen Pups, ob sich jemand ECC-Ram kauft oder nicht. Falls du in diesem Thread nur deine Ansicht, daß ECC-Ram besser ist als normaler Ram, bestätigt sehen wolltest, dann hab ich das falsch eingeschätzt. Die Frage, ob der Einsatz von ECC-Speicher wirklich sinnvoll ist, wäre dann ja eine andere gewesen. Übrigens: Für einen 'Problemvermeider' gibt es grundsätzlich keine sinnlosen Sicherungsvorkehrungen. Wenn du jetzt keinen ECC-Ram kaufst, wirst du Nachts keine ruhige Minute mehr haben. Jede Sekunde könnte es passieren: Ein Bit kippt um.... ganz leise.... im dunklen Datenkeller.... niemand hört es schreien.... und am nächsten morgen sind deine Daten nicht mehr das, was sie einmal waren: Geweiht für die Ewigkeit.

Gast

2011-01-06, 09:07:15

Ja ich habe dich ernst genommen, siehe z.B. die erste Anwort auf deinen zweiten Beitrag hier.
Ich bin garantiert kein 0815 User, Anwendungen, aufgestellte Maschinen inkl. Systeme bestätigen mir das. Dir muss es nicht unbedingt best#tigt werden.
Außerdem drehst du mir das Wort im Mund um: Die entscheidende Stelle punktierst des Zitats punktierst du aus... Wie bescheuert ist das denn? Wenn ich mir Speicher kaufe, überprüfe ich ihn vor Anwendung. Ob mit oder ohne ECC, nur wenn er keine Fehler hat, wird er verwendet. Wie kommst du nur darauf zu glauben, dass nur einer hier den ECC dann trotz durch ECC erkannter Fehler weiterbenutzen würde?
SpeicherFEHLER (nicht Defekte) merkt man übrigens nicht zwangsläufig mit Memtest. Es geht in erster Linie um kippende Bits, nicht um kaputte Schaltungen.
"ECC bei Arbeitsspeicher ist ein Algorithmus mit dem versucht wird ein Serversystem stabil zu halten und Systemabstürze zu vermeiden"
Kann gut sein, das sind aber nur einige der Effekte. Welche Auswirkungen ein gekipptes Bit hat kannst du doch gar nicht wissen: Ob das System abstürzt oder anstatt dessen ein Fehler geschrieben wird, weil ein Bit gekippt ist, kannst du doch gar nicht vorraussehen.

Kippende Bits entstehen - wie hier, so glaube ich, schon einmal angemerkt wurde - vor allem durch kosmische Strahlung oder ähnlichem. Daraus folgt übrigens auch, dass bei größerer Speichermenge die Wahrscheinlichkeit für einen Treffer steigt. Außerdem werden die Schaltungen bei größeren Speichermengen (historisch gesehen) physikalisch immer kleiner. Das senkt die Bereitschaft für solch ein Kippen.
"Das läßt du dir dann am besten vor dem Kauf nochmal schriftlich geben." Ehm, ja mach ich. Wo ist das Problem?

Zur Degradation: Wie gesagt, die Schaltung muss ja nicht zwangsläufig kaputt sein um einen Fehler zu produzieren.

Was für Anforderungen ich habe musst du mir überlassen. Da ich seit Jahren nur sehr günstige, stromsparende CPUs verwende, weiß ich doch ziemlich genau, was auf mich zukommt: Ein System, das wieder einmal schneller ist als das vorherige und gleichzeitig weniger Strom verheizt.
Warum ich mir kein richtiges Serversystem kaufe? Tja auch da gibts mehrere Gründe:
1. kostet ein "professionelles" System, welches die gleichen Aufgaben erfüllen kann wie meines, ein Vielfaches (ja ein Vielfaches, also in meinem Fall dann nicht mehr 1000€, eher 3000€ oder mehr). Auf den guten Support ist auch gepfiffen, ich werde keine monatlichen Beiträge zahlen...
2. wird kein fertig kaufbares System so leise sein wie mein Eigenes. Und wenn ich bei nem gekauften Serversystem nen Lüfter austausche, stehe ich vermutlich wieder ohne jegliche Gewährleistungen da. Zurecht wie ich finde.
Diverse andere Sachen könnten hier noch zusätzlich aufgeführt werden. Ich verzichte, ist zu viel Arbeit.

Scheinbar ist der Berufsstand "Freiberufler" für dich weder seriös noch ehrbar. Ziemlich anmaßend, wie ich finde. Ich will trotzdem nicht weiter auf meine beruflichen Umstände eingehen, es sei dir gesagt: Meine anfänglichen Gedanken sind gerechtfertigt.

Für den Thread muss man übrigens nicht Psychologie studiert haben. Ich würde es viel besser, wenn die Leute hier Physik, Elektrotechnik und Informatik studiert hätten (was einige vermutlich auch haben). Dadurch sind sie nämlich eher dazu befähigt, mir vernünftige Antworten auf ein gar technisches Problem zu liefern.

Scheinbar bin ich mit meinen Gedankengängen bezüglich des Themas auch nicht allein, andere Leute haben auch schon spekuliert, das stimmt mich positiv.

GloomY

2011-01-07, 03:27:32

Und ich schlag dir folgendes vor: Behandel andere Leute nicht wie Idioten. Ich habe nicht behauptet, daß ich mich mit dem ECC-Verfahren auskenne.Du hast behauptet:
Von echter Ausfallsicherheit kann also auch im Serverbereich schonmal nicht die Rede sein.Ich kann es nicht haben, wenn Leute Dinge behaupten, obwohl sie nicht mal verstehen, wie die zu grunde liegenden Verfahren überhaupt funktionieren und somit vollkommen falsche Schlüsse ziehen.

Ach wirklich. Und du meinst, daß sich der 0815-User darüber im klaren ist, was ihm der ECC-Count sagt? Oder was ein permanent auftretender ECC-Fehler wirklich bedeutet?Darum geht es doch gar nicht.

Und JA! es gibt sie noch: Ram-Module, die einfach mal funktionieren... ganz ohne Hokuspokus. Und von diesen sollen es sogar eine Menge seinAuch ein sonst einwandfrei funktionierendes Modul kann sich nicht gegen kosmische Höhenstrahlung wehren.

Wenn man die Fehler ohne den ECC-Check nicht bemerken würde, dann frage ich mich: Wozu dann ECC? Ist ECC reiner Selbstzweck?Nicht jeder Bitfehler führt direkt zum Absturz. Fehler können in freien (d.h. nicht verwendeten) Speicherbereichen auftreten und somit niemals auffallen. Sie können in verwendeten Speicher auftreten, auf den aber auf die betroffene Addresse beim nächsten Zugriff geschrieben wird (d.h. der Fehler wird überschrieben und somit nicht bemerkt). Sie können weiterhin in Daten auftreten, die nur irgendwo hin- und herkopiert werden und wo ein einzelnes falsches Bit nicht systemkritisch ist (z.B. RGB-Daten in einem BMP-File; wenn da das niederwertigste Bit in einem Farbkanal kippt, kannst du den Unterschied zum Original wahrscheinlich nicht mal optisch sehen).

Obwohl in all diesen Fällen Bitfehler auftreten, führen sie das System nicht zum Absturz und sind für den Menschen nicht sichtbar. Aber es ist falsch davon auszugehen, dass es diese Fehler nicht geben würde, nur weil man nicht direkt eine Wirkung erkennen kann.

Daher wäre es recht interessant, ob du unter diesem Aspekt auch nochmal was zum Thema dieses Threads sagen könntest:
ECC Speicher sinnvoll?
Wozu der TS ECC haben möchte, hat er ja oben dargelegt.Ich denke auch schon längere Zeit darüber nach mir ECC Speicher zuzulegen. Es mangelt bei Consumer-Hardware aber leider oft an der Unterstützung und teure Server-Boards kann ich mir momentan nicht leisten. An sich halte ich es für sinnvoll. Und gerade wenn die Modul-Preise sich nicht wirklich groß unterscheiden bezüglich mit und ohne ECC, werde ich beim nächsten Systemkauf mir ECC zulegen, wenn es preislich insgesamt (Module, Board etc.) nicht all zu sehr teurer ist.

Die ECC-Korrektur muss(?) durch die CPU erfolgen. Es wäre mir jedenfalls neu, daß ECC-Ram den Fehler gleich selbst korrigiert. ECC-Ram liefert nur eine erweiterte Bitfolge ab, die dann nachträglich durch einen Algorithmus interpretiert werden kann. Dieser Algorithmus kostet Performance. Und da er bei jedem Speicherzugriff (quasi mit jedem Takt) auftritt, wäre es ungemein interessant mal zu erfahren, wieviel Performance tatsächlich auf der Strecke bleibt. Auch wäre es interessant zu erfahren, wo diese zusätzlichen 8 ECC-Bit generiert werden. Ich habe den 'dringenden Verdacht', daß dies ebenfalls die CPU übernehmen muss. Ein zusätzlicher Controllerchip, der diese Aufgaben erledigen könnte, ist auf dem oben von mir verlinkten Foto eines ECC-Moduls nicht zu erkennen.Das macht üblicherweise der Speichercontroller bei DRAM. Er generiert die ECC bits bevor er sie ins Modul schreibt und prüft diese wieder nach dem Auslesen.

Hättest du den Thread aufmerksamer gelesen, dann wäre dir auch nicht entgangen, daß es bereits CPUs gab und gibt, bei denen sich über das BIOS ein ECC-Algorithmus für den Level 2/ Level3 -Cache aktivieren ließ. Der hierdurch verursachte Performanceverlust war (wenn man den Berichten im Netz glaubt) mehr als deutlich. Hätte man besser implentieren können/müssen sagst du. Hmm... ich seh das eher pessimistisch und glaube, daß die Leute, die das damals 'verbrochen' haben, schon ziemlich gut waren in ihrem Fach.Der Performanceverlust bei ECC ist meines Wissens vor allem auf Sub-Wort Schreibzugriffe zurückzuführen, also wenn du weniger als das gesamte Wort schreibst, das mit ECC geschützt ist. Dann musst man nämlich auch die ECC-Werte anpassen und dazu musst du erstmal die alten Daten (d.h. die Daten, die nicht verändert werden) lesen, dann die Änderung an entsprechender Stelle einfügen, ECC über diese neuen Daten berechnen und das ganze dann wiederum abspeichern. Das dauert halt länger als ohne ECC, wo man einfach nur die neuen Daten an die entsprechende Stelle schreiben muss und den Rest einfach unverändert lassen kann.

Bei viele ISAs (darunter auch x86) kann man eben auch einzelne Bytes in den Speicher (d.h. in den Cache) schreiben und nicht nur Daten in Registergröße (d.h. 32 oder 64 bit). Dann muss man eben einen read-modify-write Zyklus machen statt eines einfachen (partiellen) write.

SDRAM (ebenfalls DDR1, 2, 3, GDDR1-4 etc.) unterstützt Subwort-Zugriffe (per Write Mask), aber sie sind eben nicht üblich. Der Speicher tauscht nicht einzelne Bytes mit der CPU aus sondern immer Cachelines. Die sind immer deutlich größer als die Kanalbreite (64bit) mal Anzahl der Übertragungen pro Takt. Subwort-Writes finden also nahezu nie zwischen CPU und DRAM statt, deswegen behauptete ich auch, dass es keine Performance kostet. DMA-Geräte können tatsächlich auch mal Subwort-Schreibzugriffe machen, aber das ist so selten, dass es nicht ins Gewicht fällt.

ECC im Cache ist natürlich etwas anderes, weil dieser Subwort-Schreibzugriffe unterstützen muss. Da kann es schon sein, dass man ECC an oder aus messen könnte.

GloomY

2011-01-07, 03:30:14

Doppelpost. Ich sollte so langsam ins Bett gehen... :sneak: :whistle:

Gast9t99 (0815)

2011-01-07, 04:10:21

Ich bin garantiert kein 0815 User, Anwendungen, aufgestellte Maschinen inkl. Systeme bestätigen mir das. Dir muss es nicht unbedingt best#tigt werden.
Es gibt jetzt sogar schon eine Anwendung die einem bestätigt, daß man kein 0815-User ist ?! ;) ....Mit der Idee könnte man in Deutschland wahrscheinlich richtig Geld verdienen. Ansonsten kann ich dazu nur sagen: Selbsterkenntnis ist der erste Schritt zur Besserung. Da ich mich selbst in vielen Anwendungsbereichen eines PCs für einen 0815-User halte, nimm es mir bitte nicht übel, wenn die Latte für Leute, die die IT-Welt gerne etwas abgehoben 'von oben' betrachten, überraschend hoch hängt. Wer in meiner Welt kein 0815-User sein will, der muß schon in der Lage sein mich in Staunen und Ehrfurcht zu versetzen. Könnte selbst für einen ausgewiesenen IT-Experten schwierig werden. - Mehr sag ich dazu nicht.

Und du meinst, daß sich der 0815-User darüber im klaren ist, was ihm der ECC-Count sagt? Oder was ein permanent auftretender ECC-Fehler wirklich bedeutet? Ich glaube es würde sogar einige geben, die sich über das Auftreten eines ECC-Fehlers freuen: 'Schau an! - Hab ich damals doch den richtigen Ram gekauft!'.

Außerdem drehst du mir das Wort im Mund um: Die entscheidende Stelle punktierst des Zitats punktierst du aus... Wie bescheuert ist das denn?
Genauso 'bescheuert', wie der Satz imho auch mit der punktierten Stelle ist:
Wenn der Fehler nach mehreren Jahren auftritt: Ja ich würde mich freuen, am besten wäre es, wenn der Fehler noch in der Garantiezeit auftritt. Dann kann ich das Modul ohne hohe Zusatzkosten austauschen.

Wie kommst du nur darauf zu glauben, dass nur einer hier den ECC dann trotz durch ECC erkannter Fehler weiterbenutzen würde?
Ich weiß nicht wieviel Notebooks, Server, Clients und Workstations im Jahr durch deine Hände gehen. Ich kenne die Gesichter und die Geschichten dazu. Manchmal glaube ich, daß es weitaus weniger Leute sind, die sich wirklich mit ihrem PC beschäftigen, als man für möglich halten würde. Um auf die Frage zurückzukommen: Ich würde schätzen, daß so etwa 90% aller Computerbesitzer erst dann außerplanmäßig Hand an ihr Portemonnaie anlegen, wenn der Bildschirm endgültig schwarz bleibt. Ich weiß - du bist da ganz anders. Wenn der Tank im Auto leer ist, dann fährst du damit aus Prinzip sofort zur Tanke und wartest nicht erst, bis du eventuell zu spät kommst (weil du noch tanken musstest). Macht ja jeder so... kennt man ja...

SpeicherFEHLER (nicht Defekte) merkt man übrigens nicht zwangsläufig mit Memtest. Es geht in erster Linie um kippende Bits, nicht um kaputte Schaltungen.
Wie oft meinst du kippt so ein Bit und führt darüberhinaus noch zu einem Datenfehler, der nicht bemerkt wird? Und wie hoch schätzt du die Relevanz eines Datenfehlers ein, der nicht bemerkt wird?

Welche Auswirkungen ein gekipptes Bit hat kannst du doch gar nicht wissen: Ob das System abstürzt oder anstatt dessen ein Fehler geschrieben wird, weil ein Bit gekippt ist, kannst du doch gar nicht vorraussehen.
Wie ich schon oben geschrieben habe, halte ich ECC für nahezu bedeutungslos für Privatanwender. Das einzige Mal, wo ECC imho eine tragende Rolle gespielt hat, war im September 1998, als in der c't ein Tool vorgestellt wurde, mit dessen Hilfe man gefälschte Pentium-Prozessoren aus Taiwan anhand des fehlenden L2-ECC-Algorithmus entlarven konnte:
http://www.heise.de/ct/artikel/Nagelprobe-286296.html
Heute schreiben wir das Jahr 2011, und in vielen Office-Clients und Workstations steckt vielleicht inzwischen mal eine CPU mit ECC-Cache - aber immernoch kein ECC-Ram. Wie erklärst du dir das?
Ich erkläre mir das damit, daß Bitfehler in herkömmlichen PCs zum einen sehr selten vorkommen und zum anderen (wenn sie denn mal vorkommen) fast überhaupt keine Auswirkungen hatten und haben.

Kippende Bits entstehen - wie hier, so glaube ich, schon einmal angemerkt wurde - vor allem durch kosmische Strahlung oder ähnlichem. Daraus folgt übrigens auch, dass bei größerer Speichermenge die Wahrscheinlichkeit für einen Treffer steigt. Außerdem werden die Schaltungen bei größeren Speichermengen (historisch gesehen) physikalisch immer kleiner. Das senkt die Bereitschaft für solch ein Kippen.
Ich bin mir nicht sicher, ob du dir darüber im klaren bist, um welche Speichermengen es sich in einem Server handeln müßte, damit man zu Lebzeiten ein kippendes Bit beobachten darf, welches eindeutig nicht auf Degradation oder einen Materialfehler im Chip, sondern auf kosmische Strahlung zurückgeführt werden kann. Ich halte die Geschichte mit der kosmischen Strahlung übrigens für einen Witz. Vielleicht lieg' ich damit falsch - aber die Wahrscheinlichkeit, daß es gelingt mich vom Gegenteil zu überzeugen ist astronomisch gering. Wenn jemand an seinem PC-Gehäuse außen einen Blitzableiter anbringt, hätte ich nicht weniger gelacht. Vielleicht hilft dir dieser Artikel aus der c't bei deiner Frage nach dem Sinn von ECC-Ram ein bischen weiter:
http://www.heise.de/ct/hotline/ECC-Speichermodule-311974.html
Diese so genannten ‘Soft Errors’ sind bei modernen DRAM-Bausteinen extrem selten. Defekte Speicherchips fallen im Unterschied dazu meist durch Multibit-Fehler auf, die sich per ECC nicht korrigieren lassen.
(..)
ECC lohnt sich bei gewöhnlichem Betrieb eines PC, der üblicherweise mindestens einmal täglich neu bootet, eher nicht.
(..)
Die ECC-Funktion ist in dicken Servern mit riesigem Hauptspeicher nötig, um kritische Daten dauerhaft vor Fehlern zu schützen.

Und wenn in der c't von 'riesigem Hauptspeicher' die Rede ist, dann meinen die das im Zweifel auch so. Also nicht irgendwelchen Nippes im 10"-Rack. Auch über die Einschätzung der Fehlerhäufigkeit als 'extrem selten', würde ich mir mal ein paar Gedanken machen.

Hier mal ein Anhaltspunkt:
Mit MAX5 Skalierbarkeit bietet der HX5 Blade Speicherkapazitäten bis zu 640 GB
http://www-03.ibm.com/systems/de/bladecenter/hardware/servers/hx5/index.html
Wenn man mit denen erstmal den ganzen Keller voll hatt, dann ist man für ECC dankbar. Ab 640 GB könnte ein Speichertest etwas länger dauern.... Wieviel GB wolltest du in deinen 24/7-Server doch gleich einbauen? ;)

Scheinbar ist der Berufsstand "Freiberufler" für dich weder seriös noch ehrbar. Ziemlich anmaßend, wie ich finde. Ich will trotzdem nicht weiter auf meine beruflichen Umstände eingehen, es sei dir gesagt: Meine anfänglichen Gedanken sind gerechtfertigt.
Das mit dem 'Freiberufler ohne Geld' war von mir nicht böse oder abwertend gemeint. Ich glaub das interessiert hier kaum jemanden, was du als nichtregistrierter Gast so treibst. Es wäre nur hilfreich, falls jemand abschätzen wollte für welchen Verwendungszweck deine PCs geplant sind.

Scheinbar bin ich mit meinen Gedankengängen bezüglich des Themas auch nicht allein, andere Leute haben auch schon spekuliert, das stimmt mich positiv.
Ja - und wie du am Alter des von mir verlinkten c't-Artikels erkennen kannst, philosophiert man über dieses Thema schon seit Jahren. - Vielleicht hättest du den Thread lieber mit der Frage starten sollen, ab wann der Einsatz von ECC-Speicher sinnvoll ist.

In meinen Augen macht die Geschichte mit ECC (auch in den preislichen Regionen, die du genannt hast) eher wenig Sinn. Sorry. Aber schaden würde es sicherlich auch nicht. Hätte für mich ungefähr den selben Unterhaltungswert, wie ein Kuhfänger am Smart. Wenn dann mal die Kuh über die Straße läuft, dann hat man natürlich Schwein gehabt... aber nur, wenn es sich dabei um ein kosmisch bestrahltes und mithin außergewöhnlich kleines Exemplar einer Kuh handelt:

http://www.autobild.de/artikel/frontbuegel-mit-zulassung-1234723.html?bild=bild1

:biggrin:

0815

2011-01-07, 08:00:06

wat habt ihr alle gegen mich bzw. gegen meinen nick:confused:

booomups

2011-01-08, 19:14:50

habe mich vor ein paar monaten auch einmal in die ecc sache eingelesen.

hier wurde schon vieles richtiges und wichtiges gesagt, ausser dass die von ibm eingefuerhte chipkill technik, welche mit normalem ecc speicher mehr fehler erkennen UND korrigieren kann als im normalen ecc betrieb, sowohl von amd als auch intel eingefuehrt wurde.

entweder amd oder intel benuetzen zwar einen anderen namen als chipkill, aber mit google findet einiges mit den stichworten ecc chipkill und amd oder intel.

amd hatte das schon in opteron prozessoren im sockel 754 bzw s939, also schon ein paar jahre.

leider konnte ich keine aktuellen informationen finden die funktionierende software und hardware konfigurationen nennen.

falls jemand gute links oder noch besser, eigenerfahrung hat, bitte melden.

aufgehoert mich zu informieren hab ich mich aber als mir klar wurde, dass mir weniger an einem perfekt fehlerfrei laufenden system liegt als an der sicherheit meiner daten.

dort heisst das ergebnis ZFS oder btrfs. Beides Dateisysteme die RAID UND PRUEFSUMMEN einsetzen, um die integritaet einzelner daten sicherzustellen.
das mit den pruefsummen fehlt meinem kenntnisstand den normalen RAID systemen. zfs und btrfs bieten auch einfache und schnelle, da intelligente backup moeglichkeiten und vieles weiteres.

Dazu copy und paste nur noch mit programmen wie fastcopy, welche die verschobene bzw kopierte datei nach dem schreiben nochmals auslesen und mit der ursprungsdatei uerberpruefen. Leider scheinen alle normalen programme ausser filesharing clients, die auf festplatten geschriebene daten nicht nachzupruefen. gibts da positive beispiele die ich nicht kenne?