Forum: PC Hard- und Software unterschiedliche Speicher-Riegel ECC/non-ECC wirklich notwendig?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Stefan H. (Firma: dm2sh) (stefan_helmert)


Lesenswert?

Hallo,

ECC- und non-ECC-Speicher-Riegel unterscheiden sich doch nicht in ihrem 
Funktionsumfang. Es ist keine ECC-spezifische Logik eingebaut.

Hat ein non-ECC-Speicher-Riegel 8 GB Kapazität und 64 Bit Busbreite, so 
hat die ECC-Variante 9 GB Kapazität bei 72 Bit Busbreite. Wo die 
ECC-Information gespeichert ist, ist dem Speicher egal.

Nun kann man auch non-ECC-Speicher mittels IBECC ECC-fähig machen. Wenn 
man ECC nicht benötigt, könnte man fault injection dazu missbrauchen 
ECC-Speicher zu non-ECC-Speicher umzufunktionieren, aber mit mehr 
Speicherplatz.

Da macht es doch wenig Sinn zwischen beiden Varianten zu unterscheiden? 
Man könnte doch einfach eine Variante anbieten und selektives ECC 
erlauben. Dann könnte man Kontrollflüsse schützen, während z. B. 
Video-Streaming-Daten ungeschützt mit höherer Effizienz und geringerer 
Latenz verarbeitet werden.

Intel könnte dann die ECC-Funktionalität als nachträglich zubuchbares 
Premium-Feature per Abo-Modell anbieten. Warum hat man sich eigentlich 
nicht für diese Variante entschieden?

von Peter K. (chips)


Lesenswert?

IBECC kostet Speicherbandbreite, also Performance; - das will nicht 
jeder...
IBECC ist ja auch bei einigen neueren Intel-Plattformen einschaltbar

von Jens M. (schuchkleisser)


Lesenswert?

Stefan H. schrieb:
> Intel könnte dann die ECC-Funktionalität als nachträglich zubuchbares
> Premium-Feature per Abo-Modell anbieten.

Warte nur, das kommt schon noch.
Bitte vor dem Bootvorgang Kreditkartendaten eintragen!
Windows 12 hat kostenpflichtige Benutzerkonten...

von Sebastian W. (wangnick)


Lesenswert?

Mir hat mal ein Lieferant versucht zu erklären, dass systematische 
Einzelbitfehler bei neuen ECC-Riegeln kein Defekt seien, "weil sie ja 
korrigiert würden".

LG, Sebastian

von Lu (oszi45)


Lesenswert?

Sebastian W. schrieb:
> "weil sie ja korrigiert würden".

Mit leicht fehlerhaften Speichern kann man besonders viel Ärger haben. 
Deswegen wurde ja das Prüfbit erfunden, um solche üblen Fehler möglichst 
früh zu erkennen. Dem Verkäufer hätte ich Beine gemacht. Der verkauft 
bestimmt auch einen Sack Vogelfutter zu jeder Kuckucksuhr?

von (prx) A. K. (prx)


Lesenswert?

Viele Server protokollieren Bitfehler als Teil von deren 
Hardware-Management. Genau da Speicher mit höherer Fehlerrate 
einzusetzen, würde unangenehm auffallen.

: Bearbeitet durch User
von Lu (oszi45)


Lesenswert?

(prx) A. K. schrieb:
> würde unangenehm auffallen

Schlimmer noch! Solche Manchmal-Fehler sind nicht einfach zu finden und 
können jede Software an einer anderen Stelle treffen. Wenn bloß auf dem 
Bildschirm ein Bildpunkt fehlt, wäre es harmlos. Wenn jedoch bei der 
Gehaltsabrechnung ein Bit falsch ist, bekommen 1000 Leute kein Geld. 
Ähnlichen Fall kenne ich.

von Hmmm (hmmm)


Lesenswert?

Lu O. schrieb:
> (prx) A. K. schrieb:
>> würde unangenehm auffallen
>
> Schlimmer noch! Solche Manchmal-Fehler sind nicht einfach zu finden und
> können jede Software an einer anderen Stelle treffen.

Bei ECC-korrigierten Fehlern merkt die Software exakt gar nichts davon, 
Du wirst bloss die genannten Log-Einträge und/oder eine blinkende 
Fault-LED vorfinden.

von Michael O. (michael_o)


Lesenswert?

ECC Speicher ist nicht zur korrektion von Hardwareschrott da sondern um 
Bitfehler durch Neutrinos auszumerzen. Ist beim PC nicht so relevant, 
beim Server der Wochenlang läuft aber eher selten neu bootet kann das 
ganz andere Folgen auf die Programme und das Betriebssystem haben.

MfG
Michael

von Michael O. (michael_o)


Lesenswert?

Wie man ohne Full buffered 1TB RAM in eine 4 Sockel Maschine bekommt 
wüsste ich auch nicht, und ich habe noch nie ein FB Dimm ohne ECC 
gesehen.

MfG
Michael

von G. K. (zumsel)


Lesenswert?

Warum führt Intel so einen Affentanz um ECC-RAM auf?

von Sebastian W. (wangnick)


Lesenswert?

Lu schrieb:
> Dem Verkäufer hätte ich Beine gemacht.

Oh ja, der hat später sogar Hausverbot bekommen ...

Hmmm schrieb:
> Bei ECC-korrigierten Fehlern merkt die Software exakt gar nichts davon,
> Du wirst bloss die genannten Log-Einträge und/oder eine blinkende
> Fault-LED vorfinden.

Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung 
veröffentlicht.

LG, Sebastian

von Harald K. (kirnbichler)


Lesenswert?

Sebastian W. schrieb:
> Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung
> veröffentlicht.

Per Email? Oder meinst Du eher SNMP?

von Sebastian W. (wangnick)


Lesenswert?

Harald K. schrieb:
> Sebastian W. schrieb:
>> Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung
>> veröffentlicht.
>
> Per Email? Oder meinst Du eher SNMP?

Oh, ja, ich meinte SNMP, danke für den Hinweis.

LG, Sebastian

von Matz (Gast)


Lesenswert?

Michael O. schrieb:
> Bitfehler durch Neutrinos

Ein RAM als Neutrinodetektor halte ich für ein Märchen.

https://de.wikipedia.org/wiki/Neutrinoobservatorium

vmtl. sind schnelle Neutronen, Myonen (Höhenstrahlung) oder γ-Quanten 
gemeint

https://www.spektrum.de/lexikon/physik/gammaquant/5511

https://de.wikipedia.org/wiki/Soft_Error

von Hardy F. (hflor)


Lesenswert?

Die Bitfehler gibt es aber nunmal im Speicher. Ich setzte nach vielen 
Defekten Dateien nach dem Kopieren nun schon seit vielen Jahren nur noch 
Server und Workstations mit ECC ein.

von Matz (Gast)


Lesenswert?

Hardy F. schrieb:
> Die Bitfehler gibt es aber nunmal im Speicher.

Richtig, die gibts wirklich und die Ursache kann auch herzlich egal 
sein, weil die kosmischen Teilchen unkontrollierbar sind.

https://www.spektrum.de/news/kosmische-strahlung-verursacht-ein-sechstel-der-quantenfehler/2208778

Der Speicher als Neutrinodetektor wäre aber einen Nobelpreis wert 
gewesen ;)

von Motopick (motopick)


Lesenswert?

Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
waren solche Ereignisse alle paar Monate "normal".
So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.
Immerhin wurde die Ereignisrate ueber die Jahre dann immer duenner.
Bei Windows bin ich mir da nicht so sicher.

Ein Mainboard, dass eigentlich per Spezifikation auf unbuffered
ECC-RAM bestand, war auch mit unbuffered Non-ECC zufrieden.
Da man gekippte Bits nicht sieht, fiel das auch ueber einige Jahre
nicht negativ auf. :)
Immerhin schonte das den Geldspeicher spuerbar.

> Die Bitfehler gibt es aber nunmal im Speicher. Ich setzte nach vielen
> Defekten Dateien nach dem Kopieren nun schon seit vielen Jahren nur noch
> Server und Workstations mit ECC ein.

Nun ja. Komischerweise haben ja Archive (RAR,ZIP,etc.) Checksummen.
Das da mal etwas kaputt ist, passiert hier vllt alle 10 Jahre einmal.
Und dabei ist noch nicht mal sicher, dass das Archiv bei mir
kaputt gegangen ist, und nicht vorher schon kaputt war.
Z.B. der (Linux-)Labview-Download der c't ist so ein seltener Fall.
Der ist leider offline, und so nicht mehr verifizierbar.
Falls ihn jemand archiviert hat, koennte er ja mal gucken. :)

Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
F.U.D. halten.

von Harald K. (kirnbichler)


Lesenswert?

Motopick schrieb:
> Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
> waren solche Ereignisse alle paar Monate "normal".

Aber auch nur, wenn man RAMsch eingebaut hat. Sonst hat man solche 
Ereignisse nie gehabt.

> So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.

Bluescreen, unter Windows? Hab ich schon sehr lange keinen mehr gesehen, 
und die, die ich in den letzten Jahren sah, hatten nichts mit dem RAM zu 
tun - da ich in meinen Rechnern (und denen im Büro) keinen RAMsch 
verbaue.

Wer grindigen Billigspeicher von 3rd-Party-Assemblierern wie MDT, Adata, 
Geil & Co. verbaut, wem RGB-beleuchtete "Gamer"-Module wichtig sind, der 
wird andere Erfahrungen machen.

von Motopick (motopick)


Lesenswert?

Harald K. schrieb:
> Motopick schrieb:
>> Ja, ganz frueher™, der RAM wurde immerhin per Parity gefehlermeldet,
>> waren solche Ereignisse alle paar Monate "normal".
>
> Aber auch nur, wenn man RAMsch eingebaut hat. Sonst hat man solche
> Ereignisse nie gehabt.
>
>> So ein Windows 22H2 hat da heute deutlich mehr blaue Bildschirme.
>
> Bluescreen, unter Windows? Hab ich schon sehr lange keinen mehr gesehen,
> und die, die ich in den letzten Jahren sah, hatten nichts mit dem RAM zu
> tun - da ich in meinen Rechnern (und denen im Büro) keinen RAMsch
> verbaue.
>
> Wer grindigen Billigspeicher von 3rd-Party-Assemblierern wie MDT, Adata,
> Geil & Co. verbaut, wem RGB-beleuchtete "Gamer"-Module wichtig sind, der
> wird andere Erfahrungen machen.

Speicherriegelchen kaufte man damals bei A.Z. Elektronik.
Die "Typenangabe" war die Groesse des Riegels.
Immerhin war die Haelfte des RAMs, aus einer groesseren Menge
des guten Siemens RAMs aus Einzel ICs zusammengesteckt.
Wahrscheinlich kennst du sowas aus deinem Kuhdorf gar nicht.

Pech hatte hingegen ein Kollege, der sich etwas besonders gutes
tun wollte. Dessen RAM brauchte fuer den tollen Speed wohl einige
Zehntel Volt mehr, die sein Mainboard nicht liefern wollte.

Was du in deinem Abakus verbaust, ist mir im uebrigen voellig egal.

von Harald K. (kirnbichler)


Lesenswert?

Motopick schrieb:
> Speicherriegelchen kaufte man damals bei A.Z. Elektronik.

Du meinst den Ramschladen in der Stresemannstraße?

> Die "Typenangabe" war die Groesse des Riegels.
> Immerhin war die Haelfte des RAMs, aus einer groesseren Menge
> des guten Siemens RAMs aus Einzel ICs zusammengesteckt.

RAMsch. Sag' ich ja.

> Wahrscheinlich kennst du sowas aus deinem Kuhdorf gar nicht.

Mir scheint, Du irrst.

von (prx) A. K. (prx)


Lesenswert?

Sebastian W. schrieb:
>>> Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung
>>> veröffentlicht.
>>
>> Per Email? Oder meinst Du eher SNMP?
>
> Oh, ja, ich meinte SNMP, danke für den Hinweis.

So absurd ist SMTP keineswegs. Schon lange sind in als Server gebauten 
Systemen kleine unabhängig arbeitende Management-Systeme drin, ganz 
früher optional aber heute obligatorisch, die auftretende 
Hardware-Ereignisse melden. Und das auch per Mail können, oft mit 
eigenem Netzwerkinterface.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
> F.U.D. halten.

Es gibt sie durchaus. Wer etliche Server mit ECC-RAM im Haus hat, kriegt 
mit den Jahren schon einige Fehler zusammen. Die melden sich ja, werden 
also nicht übersehen.

Ist aber nicht sonderlich häufig. Ausser bei einer Batterie gleichzeitig 
beschaffter Server, bei der kurz nach Ablauf der 5 Jahre Wartung bei 
einem nach dem anderen die RAM Module einem Rappel kriegten.

Und genau da sind wir beim Punkt: Korrektur einzelner Bitfehler ist 
nützlich, aber die Erkennung ist wichtiger. Wenn man nicht gerade auf 
Umlaufbahn ist. Besser, die Kiste bleibt stehen, als dass sie die Daten 
allmählich unterminiert. Gutes Management schaltet ggf das betreffende 
Modul ab, wenn zu mies, und startet die Kiste mit reduziertem RAM neu.

Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne 
RAM-Chips komplett die Grätsche machen können, ohne dass die Daten 
flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also 
gewissermassen RAID 1 im RAM.

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Motopick schrieb:
>> Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
>> F.U.D. halten.
>
> Es gibt sie durchaus. Wer etliche Server mit ECC-RAM im Haus hat, kriegt
> mit den Jahren schon einige Fehler zusammen. Die melden sich ja, werden
> also nicht übersehen.
>
> Ist aber nicht sonderlich häufig. Ausser bei einer Batterie gleichzeitig
> beschaffter Server, bei der kurz nach Ablauf der 5 Jahre Wartung bei
> einem nach dem anderen die RAM Module einem Rappel kriegten.
>
> Und genau da sind wir beim Punkt: Korrektur einzelner Bitfehler ist
> nützlich, aber die Erkennung ist wichtiger. Wenn man nicht gerade auf
> Umlaufbahn ist. Besser, die Kiste bleibt stehen, als dass sie die Daten
> allmählich unterminiert. Gutes Management schaltet ggf das betreffende
> Modul ab, wenn zu mies, und startet die Kiste mit reduziertem RAM neu.
>
> Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne
> RAM-Chips komplett die Grätsche machen können, ohne dass die Daten
> flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also
> gewissermassen RAID 1 im RAM.

Meine Erfahrungen habe ich da aus der Anfangszeit, als die SIPPs
noch Parity hatten. Fehler fuehrten da zu einer Meldung des BIOS
verbunden mit einem Neustart. Das wurde ueber die Zeit aber immer
seltener. Vermutlich war im RAM irgendwo ein Nuklid verbaut, dass
nach einiger Zeit keine Neutronen mehr fuer mich uebrig hatte.
Das war auch nicht uebermaessig haeufig, als das man daraus ein
Problem haette konstruieren koennen.
Die Pruefsummen von Archiven aus der Zeit stimmen alle, also kann
es so schlimm nicht gewesen sein. Vom Fall, dass ein Einzelbitfehler
mitarchiviert wurde, vllt abgesehen. :)
Wann ich in meinem Serverchen, der natuerlich ECC hat, nachgeguckt
habe, weiss ich gar nicht mehr.
Vermutlich sind die Hersteller von RAMs auch mittlerweile sensibler
fuer das Problem, und verwenden "strahlende" Komponenten nicht mehr.

P.S.
Das Board danach hatte auch noch Parity. Bei dem sind mir Bit-Fehler
ueberhaupt nicht in Erinnerung.

: Bearbeitet durch User
von G. K. (zumsel)


Lesenswert?

Motopick schrieb:

> Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
> F.U.D. halten.

Nur weil man etwas nicht bemerkt heißt das noch lange nicht das es so 
was nicht gibt.

von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Verschärfte Konstruktionen bauen das ECC-Verfahren so, dass einzelne
> RAM-Chips komplett die Grätsche machen können, ohne dass die Daten
> flöten gehen (Chipkill). Oder spiegeln Module gleich komplett, also
> gewissermassen RAID 1 im RAM.

2. P.S.

Einfach spiegeln reicht uebrigens nicht. Fuer ein Quorum braucht
man mindestens 3 Quellen. :)

von Motopick (motopick)


Lesenswert?

G. K. schrieb:
> Motopick schrieb:
>
>> Ich wuerde die Warnung vor Bitfehlern so allgemein, also fuer
>> F.U.D. halten.
>
> Nur weil man etwas nicht bemerkt heißt das noch lange nicht das es so
> was nicht gibt.

Hat dein Rechner eine rote Warnlampe dafuer?
Oder nicht?

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:

> Hat dein Rechner eine rote Warnlampe dafuer?

Ja.

von Motopick (motopick)


Lesenswert?

G. K. schrieb:
> Motopick schrieb:
>
>> Hat dein Rechner eine rote Warnlampe dafuer?
>
> Ja.

Ach echt?
Send Pix!

Aber sie muss schon leuchten!
Sonst gueldet das nicht.

: Bearbeitet durch User
von G. K. (zumsel)


Lesenswert?

Motopick schrieb:
> G. K. schrieb:
>> Motopick schrieb:
>>
>>> Hat dein Rechner eine rote Warnlampe dafuer?
>>
>> Ja.
>
> Ach echt?
> Send Pix!
>
> Aber sie muss schon leuchten!
> Sonst gueldet das nicht.
1
[   25.337400] EDAC amd64: F17h_M70h detected (node 0).
2
[   25.337531] EDAC amd64: Node 0: DRAM ECC enabled.
3
[   25.337531] EDAC amd64: MCT channel count: 2
4
[   25.337573] EDAC MC0: Giving out device to module amd64_edac controller F17h_M70h: DEV 0000:00:18.3 (INTERRUPT)
5
[   25.337575] EDAC MC: UMC0 chip selects:
6
[   25.337576] EDAC amd64: MC: 0:     0MB 1:     0MB
7
[   25.337576] EDAC amd64: MC: 2: 16384MB 3: 16384MB
8
[   25.337579] EDAC MC: UMC1 chip selects:
9
[   25.337579] EDAC amd64: MC: 0:     0MB 1:     0MB
10
[   25.337579] EDAC amd64: MC: 2: 16384MB 3: 16384MB
11
[   25.337580] EDAC amd64: using x16 syndromes.
12
[   25.337585] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
13
[   25.337585] AMD64 EDAC driver v3.5.0

von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Einfach spiegeln reicht uebrigens nicht. Fuer ein Quorum braucht
> man mindestens 3 Quellen. :)

Du meinst also, dass RAID 1 Storage völlig für die Katz ist? :)

https://www.thomas-krenn.com/de/wiki/RAM_Mirroring
https://www.fujitsu.com/global/products/computing/servers/unix/sparc/technology/reliability/memory.html

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

G. K. schrieb:
> Motopick schrieb:
>> G. K. schrieb:
>>> Motopick schrieb:
>>>
>>>> Hat dein Rechner eine rote Warnlampe dafuer?
>>>
>>> Ja.
>>
>> Ach echt?
>> Send Pix!
>>
>> Aber sie muss schon leuchten!
>> Sonst gueldet das nicht.
>
>
1
> [   25.337400] EDAC amd64: F17h_M70h detected (node 0).
2
> [   25.337531] EDAC amd64: Node 0: DRAM ECC enabled.
3
> [   25.337531] EDAC amd64: MCT channel count: 2
4
> [   25.337573] EDAC MC0: Giving out device to module amd64_edac 
5
> controller F17h_M70h: DEV 0000:00:18.3 (INTERRUPT)
6
> [   25.337575] EDAC MC: UMC0 chip selects:
7
> [   25.337576] EDAC amd64: MC: 0:     0MB 1:     0MB
8
> [   25.337576] EDAC amd64: MC: 2: 16384MB 3: 16384MB
9
> [   25.337579] EDAC MC: UMC1 chip selects:
10
> [   25.337579] EDAC amd64: MC: 0:     0MB 1:     0MB
11
> [   25.337579] EDAC amd64: MC: 2: 16384MB 3: 16384MB
12
> [   25.337580] EDAC amd64: using x16 syndromes.
13
> [   25.337585] EDAC PCI0: Giving out device to module amd64_edac 
14
> controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
15
> [   25.337585] AMD64 EDAC driver v3.5.0
16
>

Ich sprach von Maschinen und du kommst hier mit Ersatzteilen an.


(prx) A. K. schrieb:

> Du meinst also, dass RAID 1 Storage völlig für die Katz ist? :)

Ich meine nicht, dass ist so.

Solche Feinsinnigkeiten findet man z.B. bei hochverfuegbaren
Clustersystemen.

von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Hat dein Rechner eine rote Warnlampe dafuer?

Das geht akustisch. Bei jedem Speicherfehler gibt einen kurzen Beep im 
Serverraum. 😆

von G. K. (zumsel)


Lesenswert?

Motopick schrieb:
> Ich sprach von Maschinen und du kommst hier mit Ersatzteilen an.

Kannst du das bitte in allgemeinverständlicher deutscher Sprache 
formulieren.

von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Motopick schrieb:
>> Hat dein Rechner eine rote Warnlampe dafuer?
>
> Das geht akustisch. Bei jedem Speicherfehler gibt einen kurzen Beep im
> Serverraum. 😆

Das kann man gelten lassen. Gab es bei $KUNDE auch.
Da gab es dann eine Schiffsalarmsirene aus einer Quaekbox.

von (prx) A. K. (prx)


Lesenswert?


von G. K. (zumsel)


Lesenswert?

Motopick schrieb:
>> Du meinst also, dass RAID 1 Storage völlig für die Katz ist? :)
>
> Ich meine nicht, dass ist so.

Platten im Gegensatz zu non-ECC-RAM Prüfsummen, damit ist das nicht 
total für die Katz.

von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:

> 
https://www.fujitsu.com/global/products/computing/servers/unix/sparc/technology/reliability/memory.html

Egal was Fujutsi dazu sagt, man kann aus 2 gleichgewichteten Quellen
kein Quorum bilden.

Edith: Typo

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Das kann man gelten lassen. Gab es bei $KUNDE auch.
> Da gab es dann eine Schiffsalarmsirene aus einer Quaekbox.

Wir hatten das schon. Alle paar Minuten piepste es kurz im Serverraum. 
Allerdings keine Sirene. Und dann finde mal die Quelle. :)

von Motopick (motopick)


Lesenswert?

(prx) A. K. schrieb:
> Motopick schrieb:
>> Das kann man gelten lassen. Gab es bei $KUNDE auch.
>> Da gab es dann eine Schiffsalarmsirene aus einer Quaekbox.
>
> Wir hatten das schon. Alle paar Minuten piepste es kurz im Serverraum.
> Allerdings keine Sirene. Und dann finde mal die Quelle. :)

Das haben manche USVen auch. :)

von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Egal was Fujutsi dazu sagt, man kann aus 2 gleichgewichteten Quellen
> kein Quorum bilden.

Muss man auch nicht. Man muss nur wissen, welche Seite Mist liefert. Bei 
HDDs ist das deren CRC/ECC. Bei RAM-Mirroring auch. Hilft bei 
erkennbaren Mehrbitfehlern und bei Totalausfall von Chips.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

G. K. schrieb:
> Platten im Gegensatz zu non-ECC-RAM Prüfsummen, damit ist das nicht
> total für die Katz.

Nix Gegensatz. Die RAMs haben das ja auch. Mirroring ersetzt keine 
Prüfsumme im RAM, sondern wirkt zusätzlich.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Motopick schrieb:
> Solche Feinsinnigkeiten findet man z.B. bei hochverfuegbaren
> Clustersystemen.

Ein Quorum für Verfügbarkeit solcher Systeme ist eine andere Baustelle.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.