Hallo Besucher, der Thread wurde 11k mal aufgerufen und enthält 70 Antworten

letzter Beitrag von androSID am

ECC-Ram

    Zitat von CommieSurfer

    Festplatten kann man ja auch nicht zu 100% auf ewig vertrauen, da würde ich eher darauf die Priorität verlegen.

    Fesplatten und SSDs wären ohne ECC schon lange unbenutzbar. Die verwenden allerdings kompliziertere Algorithmen als man für ECC bei RAM verwendet. Frag mal die SMART-Werte deiner HDs ab und schau nach 'hardware-ECC-recovered' oder ähnlich.



    Zitat von CommieSurfer

    Eher gewinnt man in der Lotterie, als dass sich das genau in dem einen Moment beim Absaven eines Dokumentes ereignen würde

    Die Datei steht beim Bearbeiten / Erstellen die ganze Zeit im RAM, Bits können da jederzeit kippen. Vorsicht mit solchen Aussagen zur Wahrscheinlichkeit, das menschliche Hirn ist nicht besonders gut darin sie zu beurteilen und abzuschätzen.


    Ein anderer Grund für die Verwendung von ECC ist Rowhammer. Damit kann man Bitkipper provozieren (und, schlau gemacht, root-Rechte bekommen!) indem man immer dieselbe Speicherzeile ausliest und damit, mit gewisser Wahrscheinlichkeit, die danebenliegende Zeile beeinflusst. Hohe Integration lässt grüßen... Details hier: https://de.wikipedia.org/wiki/Rowhammer
    (Rowhammer via Javascript im Webbrowser ist besonders interessant)


    ECC hilft hier da der erste so erzeugte Zweibitfehler das System abschiesst. Die Logs lesen ist dann sehr aufschlussreich.

    Zitat von Phasengleich

    Was ist eigentlich mit den ganzen Fimen Laptops, Macbooks, Behördenrechner, Arbeitsrechner bei Firmen. Das sind ja alles extrem wichtige Arbeitsgeräte. Wie viele von denen haben ECC RAM verbaut?

    So gut wie keine und das ist durchaus ein Problem. Bei Laptops gibt es von Lenovo welche mit, alle anderen haben keines.

    Zitat von Phasengleich

    sind RAM-Fehler nicht was extrem seltenes? Ich meine nicht dass RAM defekt ist, sondern dass ein oder mehrere Bits kippen durch kosmische Strahlung usw.

    Ja und nein. Sie sind selten in dem Sinne, dass kosmische Strahlung am Erdboden nur noch relativ schwach ist - die in Satelliten und Weltraumsonden verbaute Elektronik muss deutlich mehr aushalten können. Allerdings ist die Strahlung durch direkt im Chipgehäuse vorhandene radioaktive Atome unabhängig von der Höhe und lässt sich nicht vermeiden.


    Andererseits wird das Problem durch die fortlaufende Miniaturisierung immer schlimmer: Im C64 sind auf der Platine 64 KiB dynamisches RAM verbaut, und jedes Bit davon ist für heutige Standards relativ "groß".
    In einem modernen PC enthält die gleiche Grundfläche das Millionenfache an Speicher, und die einzelnen Bits sind "kleiner".


    Es ist also denkbar, dass eine ionisierender Strahlung, die in einem C64 keines der Bits gestört hätte, in einem aktuellen PC gleich mehrere Speicherzellen beeinflusst - da die RAM-Hersteller um das Problem wissen und daran arbeiten, kann man natürlich nicht linear hochrechnen.

    Ich arbeite und beschäftige mich seit 1987 mit PC, beruflich und privat, und habe noch nie den Bedarf gesehen nach ECC-RAM,
    egal ob mit einem XT, AT, 386er, 486, Pentium1,2,3,4, Core2Duo, i3, i5, i7, eigentlich war da nirgendwo ECC-RAM drin.
    Beruflich jeden Tag 8 Stunden ist der PC/Notebook in Gebrauch, dazu kommt sicherlich noch 1 -2 Stunden täglich den privaten Gebrauch,
    und alles funktionierte auch ohne ECC-RAM bisher ohne Probleme.
    Klar gibt es sicherlich Bereich wo ECC sinnvoll sein kann, z.B. im Workstationsbereich oder bei komplexen Datenbank-Anwendungen oder eben im Server-Bereiche oder in der Wissenschaft oder in der Hightech-Entwicklung.
    Wenn ECC wirklich sooo wichtig wäre, dann würde man es wohl überall einsetzen, denn die Aufpreise für ECC sind eher gering, aber so wie es scheint ist es dass eben nicht und somit ist ECC in vielen PC-Bereichen nicht nötigt.

    Zitat von Gerrit

    Fesplatten und SSDs wären ohne ECC schon lange unbenutzbar. Die verwenden allerdings kompliziertere Algorithmen als man für ECC bei RAM verwendet. Frag mal die SMART-Werte deiner HDs ab und schau nach 'hardware-ECC-recovered' oder ähnlich.


    Die Datei steht beim Bearbeiten / Erstellen die ganze Zeit im RAM, Bits können da jederzeit kippen. Vorsicht mit solchen Aussagen zur Wahrscheinlichkeit, das menschliche Hirn ist nicht besonders gut darin sie zu beurteilen und abzuschätzen.
    [...]

    Hast du denn oder je einer -mit ordnungsgemäß, Ram fehlerfrei funzenden System- wirklich 'mal eine falsche Datei herausbekommen ? Das meinte ich vorher schon mit "Welchen Nachteil hätte man überhaupt.. ?". Ich glaube kaum.
    Ich könnte 20 Mal dasselbe Video oder MP3 encoden lassen, Kopieren (von CD-R auf Festplatte oder von Festplatte zu Festplatte, wie auch immer eben).
    Alle 20 Resultate hätten garantiert -bei einem normal funzenden System- dieselbe z.B. MD5 Hash Datei-Checksum (= 100% indentische Dateiresultate). Das reicht mir, um für mein Gehirn zu wissen, dass da im Grunde so gut wie nie etwas schiefläuft / sich keine Bitfehler einschleichen. So einfach ist das.
    [Im Professionellen Bereich (in Firmen, wo das ganze zudem ohne Unterbrechung im Serverschrank vor sich hin läuft) muss man natürlich besser noch sensibler (ultra sensibel) sein, das ist schon klar. Dem habe ich auch nicht widersprochen.]


    Mache ich beim Kopieren stichprobenmäßig auch jedesmal -weil ich da ja auch grundsätzlich gesehen sehr sensibel dabei bin-, die Checksummen der Dateien des org. Datenträgers mit der auf dem neuen Datenträger kurz abzugleichen.
    In eigentlich 100% der Fälle schleichen sich keine Fehler ein. Vlt. einmal in 10 Jahren könnte sowas passieren.
    U. das Wissen (durch diese Checks) reicht mir mitterweile dabei. Bin da viel beruhigter nun, als noch davor (als ich die MD5 Checksum Programme noch nicht benutzte).

    Zitat von Ezeyer

    alles funktionierte auch ohne ECC-RAM bisher ohne Probleme.

    ... die du bemerkt hast. Dieser Zusatz ist wichtig.



    Zitat von Ezeyer

    Wenn ECC wirklich sooo wichtig wäre, dann würde man es wohl überall einsetzen, denn die Aufpreise für ECC sind eher gering, aber so wie es scheint ist es dass eben nicht und somit ist ECC in vielen PC-Bereichen nicht nötigt.

    Im PC-Bereich wird knallhart kalkuliert, ECC-RAM braucht mehr RAM-Chips, ist also immer teurer als ohne. Deshalb wird es vermieden wo es geht. Der typische User schiebt Fehler und Crashes auf Windows bzw. andere Software und denkt nicht an mögliche Fehler im RAM.



    Zitat von Ezeyer

    ich arbeite und beschäftige mich seit 1987 mit PC, beruflich und privat, und habe noch nie den Bedarf gesehen nach ECC-RAM,
    egal ob mit einem XT, AT, 386er, 486, Pentium1,2,3,4, Core2Duo, i3, i5, i7, eigentlich war da nirgendwo ECC-RAM drin.

    Die alten Rechner bis zum 486 hatten typischerweise Parity auf den SIMMs. Der berüchtigte Parity-Error der das System angehalten hat ist dir sicher noch ein Begriff, oder? Abgesehen von einem Virus der eine ähnliche Meldung brachte war das ein Zeichen eines Speicherfehlers. ECC gab es dann bei einigen 486-Boards die die Parity-Bits zu (4 pro 32Bit, also 36 Bit gesamt) für ECC verwenden konnten.

    Zitat von Gerrit

    Ich hatte mal das Vergnügen einen Rechner zu sehen der seit 2 Tagen im memtest86 lief. In der Zeit wurden 3 Fehler gefunden, der erste nach mehr als 24h. Solches RAM ist defekt und muss gewechselt werden.

    Weiter oben hast du noch geschrieben, dass drei Fehler in der gleichen Speicherzelle innerhalb von 24h ok wären... ;)


    Zitat von Phasengleich

    Was ist eigentlich mit den ganzen Fimen Laptops, Macbooks, Behördenrechner, Arbeitsrechner bei Firmen. Das sind ja alles extrem wichtige Arbeitsgeräte. Wie viele von denen haben ECC RAM verbaut?

    Bei Servern ist ECC-RAM üblich - oder für sehr hohe Anforderungen sogar RAM-Mirroring zusätzlich zu ECC.

    Zitat von CommieSurfer

    Hast du denn oder je einer -mit ordnungsgemäß, Ram fehlerfrei funzenden System- wirklich 'mal eine falsche Datei herausbekommen ?

    Nein, denn solange das RAM korrekt funktioniert ist das nicht zu erwarten. Das Problem ist ohne ECC zu erkennen, wenn das RAM nicht mehr einwandfrei funktioniert.


    Zitat von CommieSurfer

    Alle 20 Resultate hätten garantiert -bei einem normal funzenden System- dieselbe z.B. MD5 Hash Datei-Checksum (= 100% indentische Dateiresultate). Das reicht mir, um für mein Gehirn zu wissen, dass da im Grunde so gut wie nie etwas schiefläuft / sich keine Bitfehler einschleichen. So einfach ist das.

    Ja... und auf meinem alten Server hatte ich mal Probleme, beim Verify des Backups fielen hin und wieder Bitfehler auf. Das lies sich lösen indem ich die RAMs in die anderen Slots gesteckt habe. Leider hatte der kein ECC, sonst hätte ich das nicht erst beim Verify bemerkt sondern sofort.

    Zitat von Unseen

    Weiter oben hast du noch geschrieben, dass drei Fehler in der gleichen Speicherzelle innerhalb von 24h ok wären...

    Das ist korrekt und bezieht sich auf das, was der Hersteller der betreffenden Server als Kriterium für einen RAM-Tausch ansieht. Erst dann gibts ein neues DIMM per Post.


    Ich sehe das für mich anders und tausche bei meinen Systemen schon deutlich früher.

    Sorry, aber da tun sich immer mehr Fragen bei mir auf:
    Wie ist das mit ECC bei Routern? Ich meine da geht ja auch teilweise extrem wichtiges rüber.
    ECC bei SPS Anlagen? Durfte ich in der Ausbildung viel programmieren.
    Wie sieht es beim C64 mit Speicherfehlern aus?
    Und ganz allgemein, hat jemand schon einmal Daten durch einen Speicherfehler verloren? Wenn ja wie oft kommt so was vor?

    Zitat von Gerrit

    Nein, denn solange das RAM korrekt funktioniert ist das nicht zu erwarten. Das Problem ist ohne ECC zu erkennen, wenn das RAM nicht mehr einwandfrei funktioniert.
    --
    Ja... und auf meinem alten Server hatte ich mal Probleme, beim Verify des Backups fielen hin und wieder Bitfehler auf. Das lies sich lösen indem ich die RAMs in die anderen Slots gesteckt habe. Leider hatte der kein ECC, sonst hätte ich das nicht erst beim Verify bemerkt sondern sofort.

    Dann also siehst du ja selbst, das es normalerweise fast egal ist. ;) Das Backup selbst war ja immerhin noch 100%ig ok, erst beim Verifying Prozess (Berechnen 'im' Ram) spielte da im Ergebnis etwas suboptimal hinein. In diesem einen Fall, so wie sich das liest.


    Klar mit ECC sieht man eher/direkt, falls der Ram irgendwo gerade kaputt geht. Das wäre schon ein kl. Vorteil.
    Solange man aber manuell immer wieder 'mal checkt (Testprogramme), ob alles noch ok / wie vorher ist, langt das ja auch fast.



    Egal, hab' eh vorher 'mal so alles entscheidene dazu gesagt u. erklärt. Für unseren Normalgebrauch.. .

    Zitat von Phasengleich

    Wie ist das mit ECC bei Routern? Ich meine da geht ja auch teilweise extrem wichtiges rüber.

    Netzwerkpakete haben eine CRC-Prüfsumme. Wenn im RAM des Routers also etwas versemmelt wird, wird der Empfänger das Paket verwerfen und neu anfordern. Wie Gerrit schon schrub: Im Grunde genommen ist heutzutage alles gesichert, nur nicht das RAM im Normalbenutzer-PC.

    Zitat von Phasengleich

    Wie sieht es beim C64 mit Speicherfehlern aus?

    In der Reparaturecke sind Speichertester verlinkt. Wenn zur Laufzeit durch ionisierende Strahlung ein Bit kippt, hängt es davon ab, wofür das Bit gebraucht wird:
    -unbenutzt: Glück gehabt
    -Grafik: "Komisch, das Pixel sieht ja ganz anders aus als sonst"
    -Code: "Drecksprogramm, schon wieder abgeschmiert!"

    Zitat von Phasengleich

    Und ganz allgemein, hat jemand schon einmal Daten durch einen Speicherfehler verloren?

    Wer schon einmal Daten durch Speicherfehler verloren hat, erfährt das ja normalerweise nicht. Daher ist auch die Argumentation "Ich brauche kein ECC, bei mir hat immer alles ohne funktioniert" fürs Klo.

    Zitat von Phasengleich

    Wenn ja wie oft kommt so was vor?

    Da verweise ich mal auf Google/Wikipedia. ;)

    Zitat von Phasengleich

    Da muss das Mainboard und die CPU mitspielen und wenn selbst mein i7 das nicht kann was müsste ich denn einbauen, ein Xeon?

    Board mit passendem Chipsatz aus der Server-Ecke und dazu passender Celeron, Pentium, Core i3 (alle nur bis Skylake) oder Xeon. Nur einen Xeon auf ein Board mit Desktop-Chipsatz setzen reicht AFAIK nicht, umgekehrt hat Intel aber mal ECC bei einigen Low-End-Consumer-Prozessoren auf Serverboards erlaubt, um im Bereich der Low-End-Server mitzumischen.

    Zitat von CommieSurfer

    Dann also siehst du ja selbst, das es normalerweise fast egal ist. Das Backup selbst war ja immerhin noch 100%ig ok, erst beim Verifying Prozess (Berechnen 'im' Ram) spielte da im Ergebnis etwas suboptimal hinein. In diesem einen Fall, so wie sich das liest.

    Falsch, die Bitfehler hat er auf die HD geschrieben, ich hab den Verify mehr als einmal wiederholt und nachgehen welches Bit jetzt das Problem ist. Nachdem ein Verify bei modernen Rechnern mit Multitasking usw. niemals wirklich 100% denselben RAM-Block benutzt aber die gekippten Bits immer an derselben Stelle in der Datei zu finden waren, waren sie auf der HD. 'Silent data corruption' ist so ziemlich das Schlimmste was auf einem Computer passieren kann.


    Zitat von Mac Bacon

    Wer schon einmal Daten durch Speicherfehler verloren hat, erfährt das ja normalerweise nicht.

    Und wer es erfährt, der besteht beim nächsten Rechner auf ECC, so möglich. Die Zeit, die man zum Debuggen eines instabilen Rechners verbraucht kostet mehr als einfach ECC-RAM zu verwenden.

    Zitat von Gerrit

    Falsch, die Bitfehler hat er auf die HD geschrieben, ich hab den Verify mehr als einmal wiederholt und nachgehen welches Bit jetzt das Problem ist. Nachdem ein Verify bei modernen Rechnern mit Multitasking usw. niemals wirklich 100% denselben RAM-Block benutzt aber die gekippten Bits immer an derselben Stelle in der Datei zu finden waren, waren sie auf der HD. 'Silent data corruption' ist so ziemlich das Schlimmste was auf einem Computer passieren kann.

    Schon gut. Das las sich in den ersten Min. nur so. - Als hätte der Ram Bank switch nur das Verifying geändert (als sei es nur darauf -das nächstliegende im Satz- bezogen gewesen).

    Zitat von Unseen

    Board mit passendem Chipsatz aus der Server-Ecke und dazu passender Celeron, Pentium, Core i3 (alle nur bis Skylake) oder Xeon. Nur einen Xeon auf ein Board mit Desktop-Chipsatz setzen reicht AFAIK nicht, umgekehrt hat Intel aber mal ECC bei einigen Low-End-Consumer-Prozessoren auf Serverboards erlaubt, um im Bereich der Low-End-Server mitzumischen.

    Danke für die Info. Ich werde ECC beim nächsten PC wohl berücksichtigen. Bei dem hier werde ich jetzt nicht CPU, Mainboard und RAM tauschen. Muss halt noch so fünf Jahre ohne ECC gehen.

    Zitat von CommieSurfer

    Ich könnte 20 Mal dasselbe Video oder MP3 encoden lassen, Kopieren (von CD-R auf Festplatte oder von Festplatte zu Festplatte, wie auch immer eben).
    Alle 20 Resultate hätten garantiert -bei einem normal funzenden System- dieselbe z.B. MD5 Hash Datei-Checksum (= 100% indentische Dateiresultate). Das reicht mir, um für mein Gehirn zu wissen, dass da im Grunde so gut wie nie etwas schiefläuft / sich keine Bitfehler einschleichen. So einfach ist das.

    Das würde schon so gar nicht funktionieren da du nicht sicherstellen kannst das der Encoder immer die selben Entscheidungen zu jeder Zeit trifft. ALLE dieser 20 Files, die alle gleich sein sollten, hätten unterschiedliche Hash Summen. Und das hat nichts mit Bitkippern oder so zu tun.

    Zitat von Sheltem

    Das würde schon so gar nicht funktionieren da du nicht sicherstellen kannst das der Encoder immer die selben Entscheidungen zu jeder Zeit trifft

    Wenn das Input-File und die Optionen beim Aufruf immer dieselben sind, dann sollte auch die Ausgabe immer dieselbe sein. Ist dem nicht so benutzt der Encoder noch anderes als Eingabe und das sollte er nicht.