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?
IBECC kostet Speicherbandbreite, also Performance; - das will nicht jeder... IBECC ist ja auch bei einigen neueren Intel-Plattformen einschaltbar
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...
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
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?
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
(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.
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.
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
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
Warum führt Intel so einen Affentanz um ECC-RAM auf?
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
Sebastian W. schrieb: > Wir haben damals EDAC-Werte über SMTP an die zentrale Überwachung > veröffentlicht. Per Email? Oder meinst Du eher SNMP?
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
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
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.
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 ;)
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.
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.
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.
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.
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
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
(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
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.
(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. :)
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?
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
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 |
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
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.
Motopick schrieb: > Hat dein Rechner eine rote Warnlampe dafuer? Das geht akustisch. Bei jedem Speicherfehler gibt einen kurzen Beep im Serverraum. 😆
Motopick schrieb: > Ich sprach von Maschinen und du kommst hier mit Ersatzteilen an. Kannst du das bitte in allgemeinverständlicher deutscher Sprache formulieren.
(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.
Motopick schrieb: > Ich meine nicht, dass ist so. Ich meine auch nicht, das ist so: https://www.fujitsu.com/global/products/computing/servers/unix/sparc/technology/reliability/memory.html
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.
(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
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. :)
(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. :)
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
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
Motopick schrieb: > Solche Feinsinnigkeiten findet man z.B. bei hochverfuegbaren > Clustersystemen. Ein Quorum für Verfügbarkeit solcher Systeme ist eine andere Baustelle.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.