[FAQ] RAID ersetzt kein Backup! und Warum eigentlich ECC RAM?

Ohne ECC Speicher können ECC Fehler gar nicht erkannt werden - also kann da auch nichts protokolliert werden!
Im besten Fall gibt es 'ne Kernel Panic und der Rechner stürzt ab, im schlechtesten Fall werden Daten u.U. unbemerkt verändert. dazwichen gibt es dann noch alle Arten von Programmabstürzen oder "unerklärlichen" nicht reproduzierbaren Fehlern.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dazu sollte man folgende Dokumentation lesen und beachten, dass es natürlich nur mit entsprechenden Systemen dort auch Informationen gibt. Ohne ECC RAM lassen sich RAM Fehler nicht feststellen, außer eben anhand ihrer Folgen und damit auch dort auch nicht auslesen.
 
Hab mal ne Mail an AMD geschrieben und darin bestätigen die den offiziellen Support für ECC bei den Pro CPUs.
 
Warum schreibt AMD dies dann nicht auf die Produktseiten der Pro CPUs?
 
Ich hab mal bei mir im Büro auf den Hauptentwicklungsserver Server geschaut (bzw. schauen lassen, kein sudo :():

36core/72thread 2x Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz, 384GB Ram
# uptime
18:05:16 up 56 days, 12:06, 1 user, load average: 31.43, 31.92, 22.77
# /usr/bin/edac-util --report=full
mc0:csrow0:CPU_SrcID#0_MC#0_Chan#0_DIMM#0:CE:0
mc0:csrow0:CPU_SrcID#0_MC#0_Chan#1_DIMM#0:CE:0
mc0:csrow0:CPU_SrcID#0_MC#0_Chan#2_DIMM#0:CE:0
mc0:noinfo:all:UE:0
mc0:noinfo:all:CE:0
mc1:csrow0:CPU_SrcID#0_MC#1_Chan#0_DIMM#0:CE:0
mc1:csrow0:CPU_SrcID#0_MC#1_Chan#1_DIMM#0:CE:0
mc1:csrow0:CPU_SrcID#0_MC#1_Chan#2_DIMM#0:CE:0
mc1:noinfo:all:UE:0
mc1:noinfo:all:CE:0
mc2:csrow0:CPU_SrcID#1_MC#0_Chan#0_DIMM#0:CE:0
mc2:csrow0:CPU_SrcID#1_MC#0_Chan#1_DIMM#0:CE:0
mc2:csrow0:CPU_SrcID#1_MC#0_Chan#2_DIMM#0:CE:0
mc2:noinfo:all:UE:0
mc2:noinfo:all:CE:0
mc3:csrow0:CPU_SrcID#1_MC#1_Chan#0_DIMM#0:CE:0
mc3:csrow0:CPU_SrcID#1_MC#1_Chan#1_DIMM#0:CE:0
mc3:csrow0:CPU_SrcID#1_MC#1_Chan#2_DIMM#0:CE:0
mc3:noinfo:all:UE:0
mc3:noinfo:all:CE:0
# free -m
total used free shared buff/cache available
Mem: 386468 130220 36959 7945 219288 214109
Swap: 0 0 0

Auf dem wird nächtlich jeder Workspace von den Entwicklern, die auf der Maschine sind, gesynct und gebaut, zusätzlich wird tagsüber der Server mit dem Clangbackend, kompilieren und Testläufen gequält. Bei 384GB kein Fehler seit knapp 2 Monaten (danke Stromausfall...). Aber für mich bedeutet das, dass ich mich bei dem kleinen 16GB Ram Heimserver nicht um ECC kümmern werde.

Andere Meinungen zu den Zahlen? Hat jemand andere Zahlen zu DDR4? Überraschend oder erwartet?
 
Aus einem Samplessize von 1 solche Schlüsse zu ziehen ist schon extrem mutig. Aber ich wünsche Dir das es trotzdem gut geht.
 
Die Stichprobengröße ist eben nicht 1. Auf eine Größe von 1 zu schließen zeugt meiner Meinung nach von Unwissen.

Die Samplesize ist 4 Speichercontroller und 12(?)*18 DDR4 ICs auf 56Tage.

Aber trotzdem ich bin sehr an weiteren Logs interessiert. Ich kann mich auch mal die Woche in der Firma umhören, was wir noch an DDR4 Kisten rumstehen haben, allerdings haben die alle nur 57 Tage uptime momentan.
 
Zuletzt bearbeitet:
Das ist ein System mit ein "paar" Speicherzugriffen.

Ich denke, du solltest wiederkommen und Aussagen zu dem Thema treffen, wenn du bei 10^10000000000000000000000000000 Zugriffen bist.
Ansonsten ist die Samplezise von einem System, was ein paar Tage läuft in etwas genauso viel wert, wie die Aussage, dass Auto Fahren die sicherste Fortbewegungsmöglichkeit weltweit ist, weil ich bisher noch keinen Unfall hatte und ich aber bestimmt schon 250k km gefahren bin.

EDIT:
Wenn deine Firma nicht gerade Amazon AWS oder MS Azuse ist, bringt deine Nachfrage garnichts. Dann sind wie bei 10 Rechnern, die ein paar Tage laufen und die noch immer keine statistische Relevanz haben.
 
[…]Ich denke, du solltest wiederkommen und Aussagen zu dem Thema treffen, wenn du bei 10^10000000000000000000000000000 Zugriffen bist.
[…]
Wenn deine Firma nicht gerade Amazon AWS oder MS Azuse ist, bringt deine Nachfrage garnichts. Dann sind wie bei 10 Rechnern, die ein paar Tage laufen und die noch immer keine statistische Relevanz haben.

Naja ich will Rückschlüsse drauf ziehen, ob ich bei meinem "kleinen 16GB Ram Heimserver" ECC brauche, von der statistische Relvanz für diesen bin ich nicht so weit weg, wie du es erscheinen sein lässt. Ich weiß auch ehrlich gesagt nicht, was das geflame von einem Super Moderator hier zu suchen hat (ala "Ich denke, du solltest wiederkommen und Aussagen zu dem Thema treffen, wenn du bei 10^10000000000000000000000000000 Zugriffen bist." usw.).
 
Also ich setzte nur voraus das ein positives Features welches garantiert da ist auch dort steht und wenn es dort nicht steht, ist es auch nicht da oder zumindest nicht garantiert, also in diesem Fall nicht validiert.
 
Naja ich will Rückschlüsse drauf ziehen, ob ich bei meinem "kleinen 16GB Ram Heimserver" ECC brauche, von der statistische Relvanz für diesen bin ich nicht so weit weg, wie du es erscheinen sein lässt. Ich weiß auch ehrlich gesagt nicht, was das geflame von einem Super Moderator hier zu suchen hat (ala "Ich denke, du solltest wiederkommen und Aussagen zu dem Thema treffen, wenn du bei 10^10000000000000000000000000000 Zugriffen bist." usw.).
@Namenlos
Doch, du bist sehr weit weg von statistischer Relevanz.
Ich greife nochmal ein Autobeispiel auf:
In .de werden am Tag millionen von Kilometern mit angelegtem Sicherheitsgurt gefahren.
Wirklich relevant ist er nur im Unfallfall. Sprich also, mal aus der Luft gegriffen, auf einem Kilometer ist er nötig, weil statistisch gesehen auf genau "diesem" Kilometer ein Unfall passiert und der Sicherheitsgurt dann zur Anwendung kommt.
Jetzt könnten ja alle anderen Autofahrer, die die restlichen Kilometer fahren, auf die Idee kommen, morgen brauche ich keinen Anlegen, weil ist ja heute nichts passiert.
Wer sagt denn diesen Autofahrern, dass nicht genau einer von denen, morgen mit seinem Unfallkilometer dran ist und einen Unfall baut, wo der Sicherheitsgurt dran ist.
Denn die Statistik sagt, dass morgen wieder einen mit dem Unfallkilometer dran ist.
Wie willst du also mit der Beobachtung von 384GB RAM über 56Tage statistisch relevante Aussagen treffen, wenn auf der Welt 10000000000000000000000000000TB RAM 24/7 laufen und RAM-Fehler in keister Weise dauerhaft statistisch erfasst werden.

Auf dich angewendet:
Auch wenn du morgen mit dem Auto nur zum Bäcker fährst, kannst du "dran" sein.
Es steht dir frei, dabei einen Sicherheitsgurt zu benutzen oder nicht. Aber glaube nicht, nur weil du zum Bäcker fährst (der mehr "100m" weg ist) du plötzlich kugelsicher bist, weil du sonst immer 10km zur Arbeit fährst und nix passiert.
Der Sicherheitsgurt ist eine Versicherung. Versicherungen braucht man nur, wenn etwas passiert und sonst nicht.

Und genauso verhält es sich mit dem ECC. Brauchen tut ihn keiner, Rechner gehen auch so. Sie sollen aber verhindern, dass bestimmte Speicher"defekte" auftreten.
Und diese Speicher"defekte" passieren, genauso wie Unfälle passieren, und man hofft immer, dass man nicht dran ist.

Du kannst bei dir auf Arbeit feststellen, dass alle eure Rechner über 365Tage kein Speicherproblem hatten. Und dennoch bauste dir morgen nen neuen Rechner hin und der stürzt direkt 10min später mit einem RAM-Fehler ab. Warum?
Weil die Server bei dir auf Arbeit quasi die "passiertnichtZeit" aufgebraucht haben und dein Rechner dann dran war und in die passiertwasZeit gekommen ist.
Das, leiber namenlos, nennt man Stochastik. (du kannst 100x die 1 Würfeln und ich Würfel beim ersten Mal direkt die 6)

Um dich mal schlau zu machen:
Das ist eine aussagekräftige Statistik von Leuten, was Statisik ist:
About a third of machines and over 8% of DIMMs in our fleet saw at least one correctable error per year. Our per-DIMM rates of correctable errors translate to an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit and a median FIT range of 778 –25,000 per Mbit (median for DIMMs with errors), while previous studies report 200-5,000 FIT per Mbit.

Es steht dir frei, ECC zu nutzen oder nicht, aber das, was du da versuchst ist nicht mal im Ansatz eine fachliche Grundlage für eine Entscheidung. Es mag eine Entscheidungsgrundlage für dich sein, hat aber nichts mit der Realität und schon garnicht mit dem Businessumfeld zu tun.
Um dir die Entscheidung zu vereinfachen, kannst du auch ne Münze werfen, hat in etwas die selbe statische Relevanz wie deine Beobachtung.

Ich sehe kein geflame, sondern nur den Hinweis, wie man statistische Auswertungen von Beobachtungen macht und darauf aufbauend Ausfallwahrscheinlichkeiten berechnet.
Und mein Super Moderator-Status hat beim Fachthema garnichts zu sagen.
 
Zuletzt bearbeitet:
Bei dem von dir verlinkten Paper ist noch von DDR1 und DDR2 die Rede und schon da ist DDR2 signifikant besser aufgestellt. Ich würde mal annehmen, das hat heutzutage bei DDR4 keine Relevanz mehr.

So makaber es klingt, ich brauche kein ECC wenn die Wahrscheinlichkeit meines vorzeitigen Ablebens höher ist als die eines Speicherfehlers in meinem Heimserver. Mir geht es einfach darum Daten zu sammeln wie wahrscheinlich denn ein Speicherfehler ist, mit dem Hintergedanken, dass 99% der Speicherfehler keine Datenkorruption auf der Storage auslösen werden.

Bei den Daten die ich geliefert habe, haben wir umgerechnet ca 50 Jahre/DDR4 IC. Das würde mit dieser kleinen Stichprobe (nicht Mal 2 Monate!) schon eine 95%tige Wahrscheinlichkeit, dass die Wahrscheinlichkeit eines Speicherfehlers pro IC pro Jahr kleiner als 5,8% ist. Reicht mir ein Konfidenzintervall von σ (~68%) wären es 2,3% und würden mir 50% reichen wäre es 1,4%. Reicht noch nicht wirklich um beruhigt zu sein oder größere Aussagen zu treffen, ist aber lange nicht so schlimm wie dargestellt. Aber genau aus dem Grund frage ich ja nach weiteren Daten. -- Das nennt man im übrigen Stochastik. Nicht das (falsche) rumgesülze über der Begriff der Wahrscheinlichkeit.

Aber was ich jetzt schon mit dieser Wirklich kleinen Stichprobe an Aussage treffen kann: Müsste ich mit diesem beschränkten Daten darauf Wetten, ob es wahrscheinlicher ist, dass ein Speicherfehler innerhalb eines Jahres in einem DDR4 IC auftritt größer oder kleiner als 1,5% ist, müsste ich darauf wetten, dass es unwahrscheinlicher als 1,5% ist.

[…]Weil die Server bei dir auf Arbeit quasi die "passiertnichtZeit" aufgebraucht haben und dein Rechner dann dran war und in die passiertwasZeit gekommen ist.[…]
Das ist Quatsch und zeugt von einem Missverständnis gegenüber Wahscheinlichkeiten.
 
Zuletzt bearbeitet:
@Namenlos
Mit den Erklärungen wollte ich dir nur nochmal näherbringen, was das grundlegende Problem von kleinen Stichproben ist.
Wenn du das nicht verstehen magst und glaubst alles besser zu wissen, dann nur zu, ich muss dich zu etwas bekehren.

Kleiner Tipp: Rate mal, warum das Paper sich Daten von Google bedient hat und nicht zu einem KMU mit 10 Servern gegangen ist?
Du hast 12 DIMMs bei 2 Monaten, das sind also gerade mal 2 Jahre Erfassungszeitraum bezogen auf 1 DIMM, wobei die Relation errors per year per DIMM ist.

Allein, dass sich jemand hinstellt, wer keine tiefe Ahnung von Speichertechnologie, Strukturbreiten sowie deren Interaktion mit der Umwelt hat und dennoch sagte "ich nehme an, dass DDR4 keine Relevanz bezüglich Bitkippern hat" zeigt schon, in wie fern man Ausführungen Beachtung schenken sollte.
Schau dir mal die Rowhammer RAM Attacke an und deren Verhalten bei DDR3 und DDR4. Wie kann das sein, wenn DDR4 ja quasi unfehlbar ist? Richtig, neue Technik, neue Komplexität.
Ich beschäftige mich tagtäglich mit der zunehmenden technischen Komplexität und der Beherrschbarkeit, sprich Robustheit sowie Verfügbarkeit/Zuverlässigkeit.
Und eins kann ich sagen, signifikant besser wird das nicht.

PS: Es hat einen Grund, warum CPU Hersteller in ihren Cache ECC einbauen, es hat auch einen Grund, warum kommerzielle Server mit ECC ausgestattet werden. Ebenfalls hat es nen Grund, warum Streamprozessoren mittlerweile auch ECC unterstützen. Und nein, der ist nicht Geldmacherei.
Des Weiteren gibt es zu dem Thema BER@RAM etliche Untersuchungen und keine lässt den (pauschalen) Schluss zu, ECC braucht man nicht. Das war noch nie so und wird wohl auch so nie werden.
Es sei denn, irgendein ganz Schlauer erfindet was ganz tolles.

Mach was du willst, aber verbreite bitte keine nicht belastbaren, angeblichen statistische Untersuchungen zu dem Thema. (denn soviel Zeit und Technik hast du garnicht, als dass das eine signifikante Stichprobe wird)
Wie gesagt, nimm eine Münze, das erspart dir viel Arbeit und vorallem spart es dir auch Zeit, weil du direkt bestellen kannst. Ob nun mit oder ohne ECC.

Es kommt auch immer auf die RAM Nutzung, deren Applikationen und deren impact an.
Wer nen Linuxserver hat und da ein wenig fileshare drauf macht, der kann ggf. auch 100 Bitfehler im Jahr haben und dadurch flipt nen Pixel in einem Bild und das bekommt der garnicht mit.
Ob der nun ECC oder kein ECC hat, ist ziemlich peng.
Dem gegenüber gibt es aber Anwendungen, die strecken schon nach einem Bitfehler die Flügel, mit zum Teil drastischen Folgen.
Ergo, nur weil jemand keine Schmerzen hat, bedeutet das nicht, dass eben selber Server/Rechner woanders auch keine Schmerzen hat.
(das sieht man schon daran, dass ich noch nie einen OfficePC mit ECC gesehen habe und trotzdem schreibt keiner mit der Schreibmaschinem weil PCs so unzuverlässig sind)
 
@Namenlos
[…]"ich nehme an, dass DDR4 keine Relevanz bezüglich Bitkippern hat"[…]

Das habe ich so nie geschrieben und das so falsch zu zitieren ist schon echt dreist. Ich habe geschrieben, dass ich glaube dein verlinktes über 10 Jahre altes Paper zu DDR1 und DDR2 hat wenig Relevanz für DDR4.

Ich weiß auch nicht was die Anfälligkeit von DDR3 und DDR4 für Rowhammer jetzt mit kippenden Bits zu tun haben soll. Die Ursachen für kippende sind bei Rowhammer andere als bei zufällig auftretenden Speicherfehlern.

Ich kann mit meinen Daten abschätzen in welchen Intervallen ich mich - zumindest für genau diese DDR4 ICs - für die Fehlerraten befinde. Das habe ich gemacht. Meinst du die Rechnung zum 95% Intervall ist falsch? Wie gesagt ich bin auch an weiteren Logs interessiert, um verlässlichere Werte für mich zu erhalten.

Wie gesagt, nimm eine Münze, das erspart dir viel Arbeit und vorallem spart es dir auch Zeit, weil du direkt bestellen kannst. Ob nun mit oder ohne ECC.
Ziehst du mit solchen Aussagen nicht deine eigene Kompetenz mit in die Lächerlichkeit?
 
Bei dem von dir verlinkten Paper ist noch von DDR1 und DDR2 die Rede und schon da ist DDR2 signifikant besser aufgestellt. Ich würde mal annehmen, das hat heutzutage bei DDR4 keine Relevanz mehr.
Das hast du geschrieben.
DDR2 ist signifikant besser als DDR1. Direkt als nächstes nimmst du an, dass DAS heute bei DDR4 keine Relevanz hat.
Damit bezieht sich das DAS (für mich) auf das "besser aufgestellt sein (von DDR2)". Und daraus wiederum ziehe ich, dass die Fehlerrate bei DDR4 keine Relevanz mehr hat und sich das DAS nicht auf das Dokumeent bezieht.

Ich weiß wie Rowhammer funktioniert.
Der Trick ist, dass es bei DDR1 und 2 keine wirkliche Relevanz hat, sondern bei DDR3 und 4 maßgeblich zum Tragen kommt.
DDR3+4 müssen also, trotz modernerer Technik, andere Probleme haben als DDR1 und 2.

Ich will nicht abstreiten, dass du für dich mit einem Stichprobe von 0 Fehlern/Jahr/DIMM bei 2 Jahren hast.
Auch ist deine Aussage zur Abschätzung der potentiellen Fehlerrate richtig.

Nehmen wir mal an, dass du bei den Versuchen bei 1% landest.
Nehmen wir mal an, die tatsächliche Fehlerrate über 1000000000000000000000000DIMMs über ein Jahr untersucht, liegt bei 0,1% Fehlerrate/Jahr/DIMM und ist damit 10x niedriger als deine Aussage.
Was bringt dir deine Untersuchung dann? Welche Aussagekraft hat das?
Du würdest dann eher nicht auf ECC setzen und die Großuntersuchung dann eher schon?

Facebook hat dazu mal (5 Jahre?) eine sehr breit angelegte Studie gemacht (über ein Jahr mit ALLEN ihren Servern), wo nicht nur der RAM oder dessen Größe, sondern viele andere Faktoren mit betrachtet wurden.
Eine Aussage von vielen war, dass moderne DRAM Fertigungstechnologien höhere Fehlerraten erzeugen.

Für dich mag das Kompetenz in die Lächerlichkeit ziehen.
Wenn du aber keine belastbare technische Faktoren (wie die Fehlerrate) hast, um eine Entscheidungsfindung herbeizuführen, dann nimmt man andere Faktoren.
Und diese anderen Faktoren sind dann nicht technische Faktoren. Wie der Name der Firma, der Support der Firma, die Farbe der Riegel, der Tagespreis, was immer es sein mag und auch das Münze Werfen kann ein solcher nicht technischer Faktor sein. Denn wo ist der Unterschied ob ich nun Kopf oder Zahl nehme oder Blau oder Geld wähle? Dadurch wird die Entscheidung nicht (technisch) fundierter.
Evtl. mache ich den Job aber auch schon zu lange, als dass ich mich damit beschäftige ob ich im Server nun 100EUR sparen kann oder nicht.

PS: Ich habe vor 20Jahren auch Server ohne ECC betrieben und das 24/7 und was soll ich sagen, bis auf die Schmerzen mit Windows war das relativ schmerzfrei. (aber da gabs noch kein DDR oder gar Fertigungsstrukturen im einstelligen nm-Bereich)

PPS: Wenn dir das Spaß macht, glaube ich, solltest du das wirklich professionell aufziehen. Irgend nen "Informatik"-Institut würde für sowas sicherlich ne Studie ins Leben rufen.
Das Thema Fehlerrate ist immer ein heißes Thema, weil man diese eben nicht mit einem Messgerät im Moment des Hinschauens rausbekommt. Sie ist aber eben auch nicht unwichtig um die Zuverlässigkeit von (aktuellen) Systemem zu bewerten, gerade in der heutigen mehr und mehr rechnerbehafteten Welt.
 
Zuletzt bearbeitet:
DUO: Exposing On-chip Redundancy to Rank-Level ECC for High Reliability
DRAM row and column sparing cannot efficiently tolerate the increasing inherent fault rate caused by continued process scaling. In-DRAM ECC (IECC), an appealing alternative to sparing, can resolve inherent faults without significant changes to DRAM, but it is inefficient for highly-reliable systems where rank-level ECC (RECC) is already used against operational faults. In addition, DRAM design in the near future (possibly as early as DDR5) may transfer data in longer bursts, which complicates high-reliability RECC due to fewer devices being used per rank and increased fault granularity. We propose dual use of on-chip redundancy (DUO), a mech- anism that bypasses the IECC module and transfers on-chip redundancy to be used directly for RECC. Due to its increased redundancy budget, DUO enables a strong and novel RECC for highly-reliable systems, called DUO SDDC. The long codewords of DUO SDDC provide fundamentally higher detection and correction capabilities, and several novel secondary-correction techniques integrate together to further expand its correction capability. According to our evaluation results, DUO shows performance degradation on par with or better than IECC (average 2-3%), while consuming less DRAM energy than IECC (average 4-14% overheads). DUO provides higher reliability than either IECC or the state-of-the-art ECC technique. We show the robust reliability of DUO SDDC by comparing it to other ECC schemes using two different inherent fault-error models.
Keywords - DRAM reliability; scaling errors; ECC;
Date of Conference: 24-28 Feb. 2018
Wenn ECC und auch die neuere Variante davon - ECC in den einzelnen Speicherchips zusätzlich zu implementieren - nicht notwendig wäre, würden sich alle Hersteller und Kunden sich dies ersparen.
Operational faults. Operational faults are also a significant concern for highly-reliable systems [20,25,26,27,28]. Field measurements on the 1.75 PFLOP Jaguar supercomputer,for example, show one DRAM operational error every 10 seconds [20].
 
Zuletzt bearbeitet:
Sammle auch seit einiger Zeit Daten/Infos für mein kommendes Eigenbau-NAS.

Was ich mich frage, wenn ECC so wichtig ist, warum verfügen die Fertig-NAS dann nicht darüber?


LG
 
Kostenfrage. Reine ECC DIMMs - welche nicht registered sind - kommen nur bei den System zum Einsatz, welche nicht viel Speicher benötigen. Intel hat bei den meisten "Desktop" CPUs seit jahrzehnten keinen [Edit]offiziellen[/Edit] Support für ECC. Dies spart je Speicherkanal 8 Datenleitungen auf dem Mainboard - von der CPU zu jedem Speichermodul.
Es hat sich jemand die Mühe gemacht, die Datenleitungen auf dem Mainboard durchzumessen:
Fehlende Verbindungen auf Desktop Mainboard ohne ECC-Support.

Die Kostenfrage ist auch der Grund, warum leider "NAS-ready" HDDs eingesetzt werden. Oder auch warum SMR-HDDs entwickelt wurden. Man bedient, je nach Anforderung, verschiedene Märkte.
Intels ECC-Support Politik
 
Zuletzt bearbeitet:
@bluesunset die meisten Desktop CPUs (Celeron/Pentium und i3) haben ECC Support (sofern passendes Chipset verwendet wird) Rest ist halt Intel Mentalität...
 
wenn ECC so wichtig ist, warum verfügen die Fertig-NAS dann nicht darüber?
Es gibt doch Modelle mit ECC, aber die kosten dann auch entsprechend mehr. Es ist aber wie überall, die Kosten sollen besonders im Consumersegment möglichst gering sein und die solange die Kisten meistens bei den meisten Users problemlos arbeiten, wird auch kein Geld für mehr Sicherheit ausgegeben, es kaufen ja noch genug Kunden. Solange man nicht gegen Gesetze verstößt und mir ist kein Gesetz bekannt welche Heimanwender zwingen würde Maßnahmen gegen Datenkorruption zu ergreifen, darf jeder jeden Mist herstellen und jeder darf sich diesen Mist kaufen. Schau Dir an was für Schrott es überall gibt der einfach nur billig ist und sich trotzdem verkauft. Es muss einfach jeder selbst entscheiden was er möchte und die für seine Anforderungen passende Hardware auswählen, was aber offenbar viele User zu überfordern scheint.
 
Ja, frag mal im Mediamarkt nach ECC... Die Antwort oder besser gesagt den "Gesichtsausdruck des schieren Unwissens" erwarte ich auch bei dem normalen User/Käufer von Fertig NAS Geräten. Sind wir mal realistisch warum sollten die soewtas wissen bzw. sich darum kümmern. Haupsache billig , Funktionsfähig und einfach zu bedienen (<--- User denken nur daran).
Auf den Packungen steht ja auch Teilweise nicht wirklich hilfreiches. XYZ-NAS... ja klar sind die Daten sicher ;)
 
Eventuell interessiert es ja jemand, mittlerweile sind es 231 Tage ohne Fehler. Irgendwann in den nächsten paar Monaten steht ein reboot an (Centos 8 ruft) und eine weitere DDR4 Maschine gesellt sich dazu (diesmal AMD).
 
Ich nehme am aktuellen Seagate-Gewinnspiel teil, weil ich die beiden IronWolf 10TB Festplatten gewinnen möchte! #runwithIronwolf
 
.... sagt mal, hab ich was verpasst oder hat Intel klammheimlich ECC Support ab dem 12500 aufwärts in deren ARK eingepflegt....

Auf der Supermicro Seite bei den W680 Boards stehen die auch....

Aktiviert Intel nun ECC bei consumer CPUs über die ganze Range mit W680?


 
Zuletzt bearbeitet:
Artikel von heise dazu:

Frag mich, ob Intel das ggf. auch wegen knapper Xeons macht. Das macht die Alder-Lake Plattform noch interessanter, weil man so hohe Singlecore-Leistung mit ECC für wenig Geld bekommen würde / bekommt.
 
Artikel von heise dazu:

... dank dir ... seit der Zwangswerbung hab ich Heise/Golem und Computerbase nicht mehr besucht

... dann muss nur noch jemand mal Unbuffered ECC DDR5 für den breiten Markt herstellen (oder ein MB mit uECC4 bauen)
... evtl stürzt sich ja Micron auf den Markt und haut deshalb die DDR4 raus (wäre ein Grund da der Bedarf von Hostern extreem sein sollte)
:)

... bisher fand ich nur Innodisk mit ner Ankündigung



.... Alderlake ist für mich interessant wegen der 8x4 anbindung der NB an die SB (wie x570 auch nur interessant war wegen der 4*4)
.... und der sehr guten Single Core Leistung mit guter Effizienz/PL bis zum 12500

da könnte ich endlich mal mein S1151 in Rente kicken :) Leider werden die W680 Boards sehr teuer
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh