Nachteile ECC?

[Fard Dwalling]

Ah. Alles klar.
Ja schon schade. Aber so ist Profit und der wirtschaftsmarkt.

 

[AndyMutz]

Sehr viel Boards Consumer Boards verweigern bei ECC UDIMMs einfach den Dienst.

ich habe diverse intel und AMD boards getestet (DDR2/DDR3/DDR4) und bisher habe ich keines angetroffen, welches nicht lief.
vielleicht war das bei den älteren generationen so, aber jedes board der letzten jahre sollte damit laufen, auch wenn die ECC funktionalität nicht genutzt wird.

-andy-

 

[Fard Dwalling]

Mh. Versteh aber trotzdem noch nicht, warum man ECC RAM kauft wenn er nicht genutzt wird.

 

[wiztm]

Ihm geht es ja darum das sämtliche Boards ECC unterstützen sollten, so wie es einmal war.

 

[panooli]

Nö. Maschinenbau / Werkzeugbau
"Gamer"RAM ist halt viel schneller, was tlw. bei CAM/CAD richtig von Vorteil ist.
Wenn die Kiste mal abkackt, interessiert es in 99% der Fälle nicht. Restart - weitermachen.
​(Kommt aber höchst selten vor!)

Diese Einstellung grenzt schon fast an Kriminell.
In 99,999...% alle fälle führen RAM-Fehler ohne ECC eben nicht zum Absturz sondern "nur" zu veränderten Daten. Bestimmt lustig wenn aus z.B. einem 12mm Blech durch eine gekipptes Bit plötzlich ein 4mm dickes wird oder Bauteile auf einmal an einer ganz Stelle positioniert ist oder eine anderes Material verwendet wird usw. Auch wenn sowas statistisch betrachtet nur alle Schaltjahr mal passiert kann dieses eine mal schon einmal zuviel sein und am ende wird einer Gesucht der bei der Konstruktion den Arbeitsfehler begangen hat.

Bei einer reinen "Spielekiste" oder "Internetbrowser-Kiste" mag das alles völlig egal sein. Bei der Bild und Filmbearbeitung mag ein verändertes Pixel auch nicht weiter Stören. Aber sowie die Daten irgendeine länger anhaltende Relevanz haben können durch RAM verursachte Datenveränderungen richtig eklig werden.

Eigene Erfahrungen dazu aus dem Bereich Softwareentwicklung und Verarbeitung größere Datenmengen.
Als Entwicklungsmöhre nimmt man ja aus Kostengründen ganz gerne mal Consumerhardware die zwar von der CPU-Leistung recht nah an der Späteren Einsatzumgebung sind aber vom Preis her nur einen Bruchteil der Serverversion kosten. Und diese wird dann auch nicht regelmäßig ausgetauscht sondern ggf. benutzt bis sie "auseinander fällt".
Berechnung gestartet die ungefähr einen Tag lang die ganzen Daten umrechnet. Das ganze drei mal laufen lassen und danach vergleichen ob bei allen drei läufen exakt das selbe Ergebnis geliefert wurde. Richtig spaßig wenn man dabei feststellt das jedesmal 1-2 Datensätze (von mehreren Mio.) anders sind. Als Softwareentwickler fängt man dann erstmal an den Fehler bei sich zu suchen und nimmt an das man irgendwo im Programm eine Race Condition drin hat die zu den inkonsistenten Daten führt. Nur wenn man denkt das ist es und verändert was und macht den Test von neuem passieren die Fehler an ganz anderen Parametern für die eine ganz anderer Programmteil für zuständig ist. Da kann man sich wunderbar Wochenlang mit Fehlersuche beschäftigen und jagt am ende nur eine Phantom.

Sehr schön auch wenn die Kiste auf der man größere Programme Compiliert RAM-Fehler hat. Da kann man auch wunderbar Phantome jagen weil nach jedem Compilieren der Berechnungsfehler an einer anderen Stelle auftritt und nicht mehr da wo man was verändert hat. Schön auch wenn man mit den ganzen Tests erfolgreich durch ist und dann nur noch mal eine kleine Kosmetische Korrektur macht und dann von den Abnahmetests die Rückmeldung bekommt was man denn da für eine Fehlerhafte Version geliefert hat.

Wobei mir selbst das bis jetzt zwei mal passiert ist und das jedesmal auf Kisten die schon einige Jahre absolut stabil gelaufen sind und sich erst mit zunehmenden Alter dann immer öfters mal "Merkwürdigkeiten" aufgetreten sind.
Das ganze waren RAM-Fehler wo selbst memtest+ garnichts bzw. nur nach mehrtägigen laufenlassen vereinzelt mal einen Fehler gemeldet hat.
Wenn die Datenmenge nur groß genug ist dann ist auf einmal jeden Tag mindestens einmal "Schaltjahr".
Bei dem einen Rechner stolpere ich über fälschlich beim Speichern veränderte Dateien selbst Jahre Später immer noch wieder mal weil ich damals einfach viel zu lange benötigt hatte bis ich überhaupt mal den RAM in verdacht hatte das der für die "Fehler" verantwortlich war.
Einen Programmabsturz oder gar Bluescreen hat es dabei übrigens keine einziges mal gegeben.


Ganz interessant dabei ist auch das wenn man z.B. solch eine größere Berechnung direkt auf dem Hostsystem laufen lässt alles einwandfrei Funktioniert. Sowie man das ganze aber auf der selben Kiste in einer VM (VMware) laufen lässt sich die Fehlerhäufigkeit um einige Zehnerpotenzen erhöht.
Spätestens wenn man sowas in einer "Produktivumgebung" einsetzt sollte man um so sensibler sein für das Thema Datenintegrität und RAM und nicht nur auf die letzten 0,1% Geschwindigkeit schauen.


Von daher freiwillig keine System mehr ohne ECC (und damit meine ich nicht nur RAM sondern die komplette Kette). Schadet nie und ist auch kein Allheilmittel gegen jedwede art von auftreten Fehlern aber auf einem System wo nicht erkennbare/korrigierbare Mehrbit Fehler auftreten, treten gleichzeitig (oder früher sogar) schon vermehrt Einzelbit Fehler/korrigierbare Mehrbit Fehler) auf.
Von daher hilft das ganze schon ganz gut um zu erkennen das die Kiste in die Jahre gekommen ist und sich so langsam anfangen Fehler einzuschleichen und es zeit wird über einem Austausch nachzudenken bevor man sich ernsthaft Daten zerschießt.

Dem Wunsch generell ECC aus Standard für alle X86 System kann mich als eigener leidvoller Erfahrung nur voll und ganz zustimmen.
An allen möglichen Stellen macht man sich seit Jahrzehnten Gedanken um die Absicherung der Datenübertragung z.B. die CRC-Prüfsummen und Paketwiederholungen bei TCP/IP, Prüfsummen auf der Festplatte und bei der Übertragung vom/zum Kontrolle usw.
Nur im größten Bereich wo alle Daten die in irgendeiner Form durch müssen (oft sogar mehrfach) ist alles ungeschützt.

Ein größeres Problem an dem ganze ist derzeit noch die Unterstützung der gängigen OS das man solche Ereignisse wenigstens in Statistischer Form vernünftig angezeigt bekommt. Wenn ECC die Regel und nicht der Exot wäre, wäre der Support mit einiger Sicherheit hier deutlich besser.

 

[Baya]

Kann jeder sehen wie er will. Wir machen uns da keine Gedanken darüber. Wie hoch ist wohl die Wahrscheinlichkeit, dass so was passiert wie du oben schreibst? Einmal in 10 Jahren? Wenn überhaupt... und selbst dann, merkt man den Fehler wohl. Denke das wird etwas überbewertet.
Wir hatten solche Fehler jedenfalls noch nie.

 

[wiztm]

Du hast nicht verstanden das es um die Datenmenge geht. Wenn Menge groß genug -> Fehler täglich

 

[helionaut]

JEDEC-Spezifikation für die bit error rate von DDR4 ist 1e-16.
Mit den theoretischen 25,6GB/s pro Channel von DDR4-3200 hat man damit pro Modul statistisch ein falsches Bit alle 108,5 Stunden.

Wegen einem falschen Bit stürzt der Rechner nicht zwingend ab, einen Fehler bemerkt man also nicht unbedingt. Mein Leben würde ich keinem Rechner anvertrauen, welcher alle 108 Stunden (oder alle 54 Stunden mit dual-channel) einen Fehler macht.

ECC ist übrigens auch die einzige Methode zur Verhinderung gezielter Manipulationen:
https://de.wikipedia.org/wiki/Rowhammer

 

[Holt]

jagt am ende nur eine Phantom.

So ist es und wenn mit dem Rechner Geld verdient wird, solle auch genug Geld für ein anständiges System mit ECC RAM (und entsprechender Plattform die das auch unterstützt) drin sein.

Wir hatten solche Fehler jedenfalls noch nie.

Zumindest noch nie bemerkt.

 

[Baya]

Naja, also ist es ja nicht so tragisch.

Im Allgemeinem liest man dass ECC eher für Server etc. gedacht ist, wo Ausfälle unbedingt vermieden werden sollen.
Was nützt mir auch in der Workstation dann der ECC, wenn auf dem Transportweg oder beim Kunden keiner verbaut ist und dort ein Fehler auftritt?! Ich halte das Thema für vollkommen überschätzt
(Also zumindest jetzt auf CAD/CAM Workstations bezogen!!)

 

[h00bi]

Was nützt mir auch in der Workstation dann der ECC, wenn auf dem Transportweg oder beim Kunden keiner verbaut ist und dort ein Fehler auftritt?!

Dass du dein Geld trotzdem bekommst. Deine Vorarbeit war ja korrekt.
Und der Transportweg geht i.d.R. über checksummengeprüfte Formate.

 

[Holt]

Eben, bei jedem vernünftigen Download wird auch eine Prüfsumme (MD5, SHA1, was auch immer) mit angegeben damit man prüfen kann, ob die Datei unverfälscht angekommen ist und gespeichert wurde. Wenn diese Prüfsumme beim Kunden passt und die Daten trotzdem inkorrekt sind, dann hat man die A*karte. Aber das muss jeder selbst wissen, ich bin froh nicht in der Firma von DerBya zu arbeiten und hoffe auch nie Kunde bei denen zu werden und würde einen Zulieferer der so verantwortungslos agiert auch nicht auswählen wollen.

 

[Baya]

Ja ich lass euch im Glauben, ECC sei das Allheilmittel.
Demnach müssten ja sämtliche Computer ohne ECC haufenweise Fehler machen und ca. 80% der Daten im Internet sind eigtl. Schrott weil da ist ja ein Bit gekippt

Hoffentlich kommt der Text den ich jetzt an einem non-ECC Computer schreibe richtig an

http://blog.grabcad.com/blog/2015/08/13/why-ecc-ram-matters/

Ne mal im Ernst, wir haben Maschinen mit Xeon / Quadro und ECC und auch welche mit i7 und non-ECC...
Es ist noch nie irgendein Fehler aufgetreten, wo plötzlich Daten verfälscht wurden.
Das der PC sich mal aufhängt oder abstürzt passiert halt alle Schaltjahre mal und nicht zuletzt liegt's dann aber am User

 

[DunklerRabe]

Wenn du schon vom Ernst sprichst, der sieht in Wirklichkeit so aus:
Es gibt professionelle Unternehmen, die sich und ihre Kunden der potenziellen Gefahr gar nicht erst aussetzen. Unabhängig davon für wie wahrscheinlich man sie hält. Das ist eine der Grundlagen bei vielen Unternehmungen, Reduzierung von Risiken.
Und es gibt diese, denen das völlig egal ist. Das sind dann halt die Ballerbuden wo man als Kunde gut beraten wäre sich jemand anderes zu suchen.

Es gibt überhaupt keinen Grund dafür RAM ohne ECC zu benutzen. Selbst in den popeligsten Desktop Kisten oder mobilen Devices sollte man das machen, denn es schadet nie. Da KÖNNTE man noch argumentieren, dass es nicht wichtig ist. Aber selbst das halte ich für zweifelhaft. KÖNNTE man vielleicht, sollte man aber nicht. Und spätestens in Systemen für den professionellen Gebrauch ist es dann gar nicht mehr diskussionswürdig.

 

[Baya]

Es gibt sehr wohl Gründe... Da wären die eingeschränkte Auswahl an CPUs und Mainboards. Zudem ist ECC immer langsamer.
Aber gut, jeder hat da seine eigene Sichtweise. Ich klink mich hier jetzt aus.

 

[Holt]

Etwas maßlos zu übertreiben und dabei andere Aussagen in den Mund zu legen die sie nie gemacht haben um diese dann im gleichen Atemzug als so lächerlich dazustellen wie sie nun einmal wirklich sind, ist ein typisches Trollverhalten. DerBaya, wenn Du also nicht als Troll bezeichnet werden willst, unterlasse sowas in Zukunft und sonst Ingorelist++.

Zu dem verlinkten Beitrag: "If you don’t mind rebooting, you don’t need ECC" geht von der blödsinnigen Annahme aus, dass sich RAM Fehler immer auch in einem instabilen Betrieb äußern. Dem ist nicht so, wie ich selbst mal vor Jahren bei einem Rechner erleben durfte, der sogar 24/7 lief und dies bis mal wieder ein Windows Update einen Reboot erforderte, aber immer wieder korrupte Archive erzeugt hat. Memtest86 zeigte klar einen Fehler in einem Modul und nach dessen Austausch war das Problem behoben, aber da Windows eben nur einen sehr kleinen Teil des RAMs mit wirklich wichtigem Programmcode und Daten (wie der RAM Verwaltung) belegt, ist die Wahrscheinlichkeit von Bluescreens bei RAM Fehlern tatsächlich sehr gering, viel wahrscheinlicher sind eben einfach korrupte Dateien oder Ergebnisse von Programmen. Die Ursache dafür wird man ohne ECC RAM auch nie definitiv ermitteln können, da nie RAM Fehler dabei steht, die können eben ohne ECC RAM nie als solche erkannt werden, sondern machen sich nur durch die Folgen bemerkbar. Nur mit ECC RAM (natürlich passender Plattform) und einer entsprechenden Überwachung kann man RAM Fehler überhaupt quantifizieren.

Übrigens zeigt das BIOS meines N54L Heimserver nur unkorrigierbare Fehler an, die Anzahl der korrigierten Singlebitfehler kann ich also nicht auslesen und trotzdem sind dort schon ein paar hinterlegt, ein RAM Riegel scheint also ein Problem zu haben, gemerkt habe ich davon aber bisher nichts, auch weil ich bisher nicht hinterlegt haben, was passieren soll wenn ein unkorrigierbarer RAM Fehler erkannt wird. Meist macht man dann eine Kernel Panik, eben um zu verhindern das falsche Daten ausgegeben werden könnten.