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

letzter Beitrag von androSID am

ECC-Ram

    Zitat von Snear

    Das konnten auch schon die Phenom II und FX Prozessoren. Problem ist, dass auch das Mainboard ECC-Unterstützung mitbringen muss. In der Vergangenheit waren das ausschließlich die Boards von Asus.

    Ich habe ein Board von ASUS und betreibe den Phenom mit ECC-RAM. Und das ist auch gut so, so alle paar Wochen habe ich einen Eintrag im Syslog, daß ein Fehler gefunden und korrogiert wurde.


    Aus diesem Grund will ich nie wieder ein Board ohne ECC-RAM, auch wenn es mehr kosten sollte.


    Nachtrag... Mit ECC-RAM hat der Rowhammer-Angriff deutlich weniger Chancen da er mindestens 3 Bits auf einmal kippen muss damit die ECC-Logic es u.U. nicht mehr erkennt. Das ist ziemlich unwahrscheinlich, davor gibt es viele 1 und 2-Bitfehler, letztere erzeugen auf einem guten OS eine sofortige Systempanic um Datenkorruption zu verhindern.

    Zitat von Gerrit

    Ich habe ein Board von ASUS und betreibe den Phenom mit ECC-RAM. Und das ist auch gut so, so alle paar Wochen habe ich einen Eintrag im Syslog, daß ein Fehler gefunden und korrogiert wurde.
    Aus diesem Grund will ich nie wieder ein Board ohne ECC-RAM, auch wenn es mehr kosten sollte.


    Hmm, hier steht seit ca. 4 Monaten ein Dell Poweredge T20 mit Xeon-Prozessor und 32GB ECC-RAM. Aktueller Status:


    Seit die Kiste hier läuft wurde noch kein einziger ECC-Fehler im syslog gemeldet. Gibt es möglicherweise eine leichte Unverträglichkeit zwischen deinem RAM und dem restlichen System?

    Zitat von Unseen

    Seit die Kiste hier läuft wurde noch kein einziger ECC-Fehler im syslog gemeldet. Gibt es möglicherweise eine leichte Unverträglichkeit zwischen deinem RAM und dem restlichen System?

    Nein, das passt schon so. Ich kenne das von der Arbeit, alle unsere Server benutzen natürlich ECC-RAM. Manche melden hin und wieder ECC-Fehler, andere nicht. Wenn nur alle paar Wochen ein Fehler auftritt kann man kaum von 'Unverträglichkeit' reden. Als defekt gilt ein RAM wenn dieselbe Speicherstelle innerhalb von 24h mehr als 3 Fehler meldet. Das OS mappt diese Page dann auch aus. Hübsch sind die Server bei denen man RAM im Betrieb wechseln kann weil man ein CPU/RAM-Board abschalten kann. Ja, auch das welches den Kernel enthält, der wird dann im Betrieb umgezogen.


    DRAM ist durch sein Funktionsprinzip anfällig für Fehler und Attacken wie Rowhammer, daher sollte ECC eigentlich Pflicht sein.

    Ich habe mich noch nie mit ECC beschäftigt. Wenn das hier in diesem Artikel stimmt, dann habe ich auch weiterhin keinen Bedarf an ECC-RAM:
    http://www.elektronik-kompendium.de/sites/com/1504141.htm



    Zitat

    Generell ist die Fehlerwahrscheinlichkeit in Prozessoren und Speicher gering. In der Regel hat man es nur mit Umgebungsstrahlung zu tun, die Fehler auslösen können.



    ECC kann 1-Bit-Fehler sofort korrigieren. 2-Bit-Fehler werden erkannt, aber nicht korrigiert. 3-Bit-Fehler können nicht alle erkannt werden. Dafür gibt es Speicherschutz-Verfahren, die deutlich mehr können.

    Zitat von Phasengleich

    Ich habe mich noch nie mit ECC beschäftigt. Wenn das hier in diesem Artikel stimmt, dann habe ich auch weiterhin keinen Bedarf an ECC-RAM:

    Deine Entscheidung. Wer schon einmal Probleme mit Speicher hatte und Stunden damit verbracht hat das instabile System zu debuggen will nicht mehr ohne ECC. Mit ECC weisst du nämlich sofort ob der Speicher ein Problem hat, ein Blick in die Logfiles reicht, ohne brauchst du Programme wie memtest86+ und selbst die finden nicht alle Probleme.


    Nebenbei müssen ECC-Module mit gutem RAM bestückt sein, die Frage nach RAMsch kommt hier erst gar nicht auf.

    Ah ok, das mit dem Protokollieren ist natürlich fein.


    Ich habe gerade mal nachgeschaut, weder mein i7 noch mein Mainboard können mit ECC was anfangen. Von daher ist ECC eh keine Option. Ich dachte man kauft einfach ECC und setzt das ein und gut ist.

    Wenn 1.) in memtest86 [benutzte "aber" noch eine Version von vor Jahren, ohne diese aktuelle/aktualisierte GUI] keine Fehler bei seinen aktuellen Ram Einstellungen auftauchen und 2.) sowieso alles ohne Abstürze läuft im OS, dann reicht das (ohne ECC) auch aus - für seine normalen Zwecke. Kein erstelltes MP3 oder encodet Video u. vorangegangenes, wird da Bitlfehler enthalten. So selten wie im Loteriespiel vlt. in etwa (wenn überhaupt).


    Vorher mit dem beschriebenen Problem ('09, '10) in meinem ersten Posting dazu, gab's aber tatsächlich ab und an komische Effekte während ich NKPro spielte.
    Da haben sich Car Setupwerte an manchem Tage im ingame Setupmuenue wie durch geisterhand um +-1 klick verändert, ohne 'was daran gestellt zu haben. Als ich darauf so spätestens ca. '11 in memtest bemerkte, dass ja der damals verbaute Ram die 4-4-4-12 gar nicht richtig schafft u. diesen darauf somit anders einstellte, waren diese Effekte nie mehr aufgetreten. Auch nicht bei 4-4-4-12 mit nun Ramriegeln die da zuverlässig bleiben.


    Das war noch so'n z.T. eher 'hardcoded' game von den 2-3 Leuten (damals, heute sind es mehr, ca. 11), da viel das zufällig noch so schön direkt auf.., wenn da eben 'was in dem Fall mit dem Ram nicht stimmte.
    Bugs hatte es natürlich auch, aber nicht diese. [Bei anderen Spielen würde / hätte es schätzungsweise wohl (leider) kein Schwein -davon etwas- bemerkt.]

    Für memtest86 gilt: Wenn das Programm einen Fehler findet, dann hast du ein Problem mit dem RAM. Wenn das Programm hingegen auch nach Tagen Dauerlauf keinen Fehler findet heisst das leider nicht, das das RAM OK ist.


    In heutigen Rechnern ist eigentlich alles mit ECC gegen kippende Bits geschützt, selbst der CPU-Cache, nur das RAM eben nicht.

    ECC erkennt aber auch nur die 1-Bit Fehler. Mehr kann das auch nicht.


    Wenn das RAM "nicht ok" ist (wie du sagtst), trotz keiner Fehler bei stundenlangem memtest (also eigetnlich doch ok, und 100% gut brauchbar). Welche Nachteile hätte man denn da ? Wahrscheinlich keine.
    Meine MP3s (selbe Quelldatei, selber Codec u. Software, jeweils) und anderes hätten ganz ganz sicher jedesmal dieselbe Dateichecksum, wie du mit dem ECC Ram ;). Als Bsp. .



    Bei Servern und anderem ganz wichtigen (Systemen im Dauereinsatz u. -Ramauslastung mit sehr viel u. viel belegtem Ram), sehe ich das auch positiv. Da muss das als ECC eine Maßnahme her.
    Sonst aber ist es scheinbar eher nur für das Gefühl. [Vorraussetzung natürlich: Der Ram u. System ist mit memtest auf größere Fehler überprüft worden.]

    Zitat von CommieSurfer

    ECC erkennt aber auch nur die 1-Bit Fehler. Mehr kann das auch nicht.


    "Nur" ist gut gesagt! Ein System das keine Fehler meldet *kann* in Ordnung sein... aber ein System das einen Fehler meldet ist definitiv nicht in Ordnung.
    Insofern finde ich es - wie Gerrit - sehr bedauerlich, das Consumer Systeme fast kein ECC haben.


    Es geht ja nicht nur darum, ob das Ding stabil läuft... was interessiert mich ob Applikation alle paar Wochen mal abstürzt.


    Ich sehe die Probleme an ganz anderer Stelle: Bei der Verarbeitung von sehr großen Datenmengen (z.B. Datenbanken, Audio/Video files etc.).
    Wenn dort z.B. beim abspeichern irgendwo ein Bit gekippt ist, fällt das keinem auf. Aber die Datei ist de-facto nicht mehr in Ordnung.
    Ein ECC würde sowas zumindest bemerken/melden.


    Sowas macht mir Sorgen:


    https://en.wikipedia.org/wiki/Data_degradation

    Zitat von CommieSurfer

    ECC erkennt aber auch nur die 1-Bit Fehler. Mehr kann das auch nicht.

    Nein, ECC erkennt und korrigiert 1-Bit-Fehler, das sind die häufigsten. ECC erkennt auch 2Bit-Fehler und löst dann, wenn das OS korrekt aufgesetzt ist, eine Systempanic aus. Das ist Absicht damit nicht mit korrupten Daten weitergearbeitet wird. Alles weitere wird nicht mehr garantiert. Damit erschlägst du den größten Teil der auftretenden RAM-Fehler.


    Zitat von CommieSurfer

    Wenn das RAM "nicht ok" ist (wie du sagtst), trotz keiner Fehler bei stundenlangem memtest (also eigetnlich doch ok, und 100% gut brauchbar).

    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.


    Zitat von CommieSurfer

    [Vorraussetzung natürlich: Der Ram u. System ist mit memtest auf größere Fehler überprüft worden.]

    Tja, nur wie lange muss der Test laufen und wie oft muss man ihn wiederholen damit man dem RAM trauen kann? Mit ECC hast du eine dauerhafte Überwachung des RAMs und bekommst gleich mit wenn es Probleme gibt.


    Hier noch ein bisschen Lesestoff zum Thema, Google hat sich damit vor einiger Zeit im Detail auseinandergesetzt:


    http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf




    Zitat von CommieSurfer

    Systemen im Dauereinsatz u. -Ramauslastung mit sehr viel u. viel belegtem Ram

    Moderne OS lasten das RAM immer möglichst komplett aus. Wenn es nicht für Programme gebraucht wird, dann wird es als Plattencache verwendet.


    Zitat von CommieSurfer

    Meine MP3s (selbe Quelldatei, selber Codec u. Software, jeweils) und anderes hätten ganz ganz sicher jedesmal dieselbe Dateichecksum, wie du mit dem ECC Ram ;). Als Bsp. .

    Ja, solange dein RAM funktioniert ist es (fast) egal ob ECC benutzt wird oder nicht. Wenn das RAM aber Defekte entwickelt (wie unsere beliebten MT4264 im C64), dann macht ECC den Unterschied, speziell im Bezug auf Bemerken des Fehlers. Das 'fast' oben bezieht sich auf die Soft-Errors, also einmalige Fehler durch kosmische Strahlung oder radioaktivem Zerfall im IC (egal wie man sich anstrengt, das Zeug ist NIE 100% frei von radioaktiven Isotopen, passiert der Zerfall zur falschen Zeit am falschen Ort liest der Leseverstärker im RAM den falschen Wert).

    Zitat von androSID

    Ich sehe die Probleme an ganz anderer Stelle: Bei der Verarbeitung von sehr großen Datenmengen (z.B. Datenbanken, Audio/Video files etc.).
    Wenn dort z.B. beim abspeichern irgendwo ein Bit gekippt ist, fällt das keinem auf.

    Ja... und beim nächsten Bearbeiten der Datei kippt vielleicht das nächste Bit... So zerlegt man sich mit der Zeit durch unerkannt defektes RAM seine Daten.

    Zitat von Gerrit

    Ja... und beim nächsten Bearbeiten der Datei kippt vielleicht das nächste Bit... So zerlegt man sich mit der Zeit durch unerkannt defektes RAM seine Daten.

    Der berühmte berüchtigte "silent bit rot"... genau aus diesem Grund bevorzuge ich auch ECC Systeme.

    @91 war das noch:
    Ja, ist schon klar. Hab' ich z.B. auch schon gemacht. Spätestens wenn man mit (meist eh sinnlosem) Übertakten so seine kl. Tests macht. Oder checkt mit vieviel Voltage unter dem voreingestellten Normalwert die CPU auf dem Standardtakt noch rel. zuverlässig läuft. [Wann da 'was nicht ausreichend abgestimmt zueinander passt, schmiert die CPU (Rechner friert ein -Bluescreen-, kommt bestenfalls noch zurück zum Desktop) zudem sogar auch beim (Heaven-)Benchmark u. dem ein oder anderen Spiel irgendwann ab.]

    Sorry für mein Unwissen in dem Bereich, aber 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. dafür ist dieses ECC doch wohl eigentlich gedacht, oder nicht?


    Was ist mit dem RAM im Festplattencontroller und in anderen Teilen eines PC-Systems. Gibt es dort auch ECC?

    Gerrit: Sind aber trotzdem -für den Normalgebrauch u. auch etwas mehr- alles eher Luxusprobleme od. "zu viel" Perfektionismus an der "falschen" Stelle.
    Da werden hier immer so seltene Fälle beschrieben (ala "wenn ein weiteres Bit bei einer erneuten Bearbeitung der Datei kippt, ist die Datei u.U. unbrauchbar", nur um zwanghaft schnell ein Beispiel zu erfinden), die einem im Leben eh nie begegnen werden.
    Selbst wenn das 'mal passieren sollte, ist es entweder kein Weltuntergang (weil es nur ein olles Video ist), oder man hat irgendwo noch andere Datei-Backups von den vorherigen Bearbeitungsschritten.
    U. ganz notfalls beginnt man eben nochmal von vorne, was aber wie gesagt eh an Wahrscheinlichkeit grenzender Unwahrscheinliochkeit sich bewegt.


    Festplatten kann man ja auch nicht zu 100% auf ewig vertrauen (darauf kippen auch 'mal Bits weg -so ich hörte-, da würde ich eher darauf die Priorität verlegen.



    Dass nicht alle naselang (bei einem mehrstündigen Gesamtspeicherplatz Check) ein Bitfehler auftritt, durch flasche Konfig. und Zusammenspiel des Systems, reicht völlig für uns hier.
    Wenn in memtest bei Dauerlast / Zugriffen und "Überhitzung" nach über 24 h 'mal ein Fehler auftritt, heisst auch noch lange nicht dass einem das am selben Tag in den gleichen 24h beim Erstellen eines Videos/Mp3s/Kopieren oder Schreiben einer Worddatei (genau in dem / in einem falschen Moment*) aufgetreten oder negativ widerfahren wäre.. .


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