Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #233429 > unrolled thread

Re: ECC-RAM

Back to article view | Back to de.sci.electronics

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 18:39 +0000
    Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-10 21:37 +0200
      Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-10 20:26 +0000
      Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:44 +0000
        Re: ECC-RAM Patrick Schaefer <pa.schaefer@web.de> - 2017-10-11 22:13 +0200
        Re: ECC-RAM Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-11 22:47 +0200
    Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-11 02:59 +0200
      Re: ECC-RAM v_borchert@despammed.com (Volker Borchert) - 2017-10-11 03:15 +0000
        Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 09:21 +0200
        Re: ECC-RAM Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-11 13:14 +0200
      Re: ECC-RAM Matthias Weingart <mwnews@pentax.boerde.de> - 2017-10-11 06:50 +0000
      Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-11 15:09 +0200
        Re: ECC-RAM Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-10-12 21:49 +0200
          Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-12 22:25 +0200
            Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-14 00:42 +0200
              Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 18:54 +0200
          Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-13 15:40 +0200
            Re: ECC-RAM Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-10-13 17:07 +0200
              Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-13 18:26 +0200
                Re: ECC-RAM Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de> - 2017-10-14 00:57 +0200
                  Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 03:21 +0200
                    Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 17:19 +0000
                      Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 21:46 +0200
                  Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 19:00 +0200
            Re: ECC-RAM Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-14 00:03 +0200
              Re: ECC-RAM Hanno Foest <hurga-news2@tigress.com> - 2017-10-14 03:37 +0200
              Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-14 18:48 +0200
          Re: ECC-RAM Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-13 22:24 +0200
    Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 14:04 +0200
      Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 18:15 +0200
        Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 18:32 +0200
          Re: ECC-RAM Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-10-11 19:00 +0200
            Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-11 22:44 +0200
    Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 11:16 +0000
      Re: ECC-RAM Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-10-14 19:23 +0200
        Re: ECC-RAM Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-10-14 18:14 +0000
      Re: ECC-RAM usenet@teply.info (Florian E. Teply) - 2017-10-14 20:23 +0200

Page 2 of 2 — ← Prev page 1 [2]

#233645

Am 14.10.2017 um 00:57 schrieb Gerhard Hoffmann:

>>> Hat der Cache, der 99% aller Zugriffe abwickelt auch ECC?
>>
>> Ja. Oder zumindest Parity - falls man sich im Fehlerfall die Daten aus 
>> dem Hauptspeicher einfach noch mal neu holen kann.
> 
> Der L1-Cache schon mal gar nicht.

Da solltest du vielleicht besser noch mal googeln.

https://en.wikipedia.org/wiki/ECC_memory#Cache

> Der L2-Cache früher manchmal,
> war aber wohlweislich abschaltbar.

Ja, früher war das mal abschaltbar, inzwischen nicht mehr und ECC ist 
immer an.

> I5, I7 haben keinen ECC-Support, da muss man schon mal in einen
> Xeon investieren.

Ich hab hier einen I3 mit ECC. Und die AMD64-Familie unterstützt 
prinzipiell ECC (aufpassen: Billig-Boards fehlen manchmal die dafür 
nötigen Extra-Datenleitungen). Daß I5 und I7 keinen ECC-Support haben, 
liegt daran, daß Intel den Consumer-Müll von den professionellen 
Angeboten abgrenzen wollte.

>>> Mit meinen Rechnern bin ich sehr zufrieden.
>>
>> Einzelfehler würdest du ja auch nicht mitbekommen. Ignorance is bliss :)
> 
> Wenn du eine ECC-Korrektur in 5 Jahren hattest,
> da muss ich ja unwissentlich durch Millionen von
> kaputten Exelfiles waten!

Noch mal explizit: Ich hatte eine ECC-Korrektur in 5 Jahren bei ECC-RAM. 
Vorher hatte ich allerdings zweimal defektes nicht-ECC-RAM, das bei 
Vorhandensein einer ECC-Funktion sicherlich unzählige Korrekturen 
ausgelöst hätte - das solltest du bei einer Statistik "falsche 
Speicher-Bits über die Zeit" mit berücksichtigen. Die dazugehörige 
Verschwörungstheorie, die auch bereits im Thread erwähnt wurde, ist, daß 
ECC-RAM von einer besseren Qualität ist als nicht-ECC, weil die 
ECC-Funktionalität nachdrücklich daraufhinweist, wenn einem Müll 
angedreht wurde.

Wenn du mehr über Speicherfehler im realen Einsatz wissen willst, 
empfehle ich https://research.google.com/pubs/pub35162.html
Caveat: Natürlich hat der gesamte dort betrachtete Speicher ECC, denn 
sonst wüßte man ja nichts von den aufgetretenen Fehlern...

Hanno

[toc] | [prev] | [next] | [standalone]

#233671

On 2017-10-14, Hanno Foest <hurga-news2@tigress.com> wrote:
> Noch mal explizit: Ich hatte eine ECC-Korrektur in 5 Jahren bei ECC-RAM. 

Ich hatte hier bis vor 1/2 Jahr einen alten Dual-Socket-Opteron als
Arbeitsplatzrechner stehen - alle paar Wochen hat der mal einen
korrigierbaren ECC-Fehler geloggt.

Gut: das waren 48GB RAM in vielen Modulen.

Ich würde den Mehrpreis für ECC-RAM-Module jederzeit wieder ausgeben - was
Intel da treibt, macht es allerdings unattraktiv, da reichlich teuer.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#233678

Am 14.10.2017 um 19:19 schrieb Michael Schwingen:

> Ich würde den Mehrpreis für ECC-RAM-Module jederzeit wieder ausgeben - was
> Intel da treibt, macht es allerdings unattraktiv, da reichlich teuer.

Dafür gibts dann ja AMD...

Hanno

[toc] | [prev] | [next] | [standalone]

#233670

On 10/14/2017 12:57 AM, Gerhard Hoffmann wrote:
> Am 13.10.2017 um 18:26 schrieb Hanno Foest:
>> Am 13.10.2017 um 17:07 schrieb Gerhard Hoffmann:
> 
>>> Hat der Cache, der 99% aller Zugriffe abwickelt auch ECC?
>>
>> Ja. Oder zumindest Parity - falls man sich im Fehlerfall die Daten aus 
>> dem Hauptspeicher einfach noch mal neu holen kann.
> 
> Der L1-Cache schon mal gar nicht. Der L2-Cache früher manchmal,
> war aber wohlweislich abschaltbar.
> 
> I5, I7 haben keinen ECC-Support, da muss man schon mal in einen
> Xeon investieren.

Deshalb kommen die mir auch nicht in den geplanten Desktop sondern ein 
Ryzen und dazu passendes ECC-RAM.

Es gibt übrigens I3, gedacht für Einsatz in NAS, die ECC können. Warum 
wohl...?


>>> Mit meinen Rechnern bin ich sehr zufrieden.
>>
>> Einzelfehler würdest du ja auch nicht mitbekommen. Ignorance is bliss :)
> 
> Wenn du eine ECC-Korrektur in 5 Jahren hattest,
> da muss ich ja unwissentlich durch Millionen von
> kaputten Exelfiles waten!

Du kannst nicht von Hannos Erfahrung mit ECC-RAM auf deine ohne ECC 
schliessen. Schon alleine deshalb nicht weil man bei ECC eben keinen 
Schrott verkaufen kann, den hat der Händler sofort wieder auf dem Tisch. 
RAM ohne ECC kann man hingegen etwas laxer handhaben... Ich hab hier ein 
System bei dem ich Speicherfehler bekomme wenn die DIMMs in zwei 
bestimmten Slots stecken und die anderen leer sind. Stecke ich die DIMMs 
hingegen in die anderen Slots geht alles. Das sind sehr seltene Fehler, 
in einer Mediendatei von > 10 GB kann es ein, daß 2 Bits kippen. Wie ich 
das ohne ECC gemerkt habe? Hin und wieder lass ich nach einem Backup ein 
'diff -r' über Original und Backup laufen.

Hanno weiss, daß sein Speicher OK war und ihm nicht die Daten 
geschreddert hat. Du weisst es nicht, du kannst es nur hoffen.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233638

Am 13.10.2017 um 15:40 schrieb Hanno Foest:

> Das ECC-RAM hat einfach mehr Bits als herkömmliches, die 
> Auswertung/Korrektur passiert in dem Chip, der den Speicher verwaltet,

ACK

> also heutzutage direkt die CPU.

Das macht meist eine MMU bzw. Bridge-Chips, nicht die CPU.
Das würde auch erfordern, daß der Datenbus die Korrekturbits zusätzlich 
überträgt. Tut er das?

DoDi

[toc] | [prev] | [next] | [standalone]

#233646

Am 14.10.2017 um 00:03 schrieb Hans-Peter Diettrich:

>> Das ECC-RAM hat einfach mehr Bits als herkömmliches, die 
>> Auswertung/Korrektur passiert in dem Chip, der den Speicher verwaltet,
> 
> ACK
> 
>> also heutzutage direkt die CPU.
> 
> Das macht meist eine MMU bzw. Bridge-Chips, nicht die CPU.

Das ist veraltet. AMD hat seit der AMD64-Architektur (also 2003) 
integrierte Speichercontroller, Intel zieht langsam nach - jedenfalls 
gibt es i3 und i7 mit integriertem Speichercontroller. AMD64 hat immer 
ECC unterstützt, bei Intel ist das von Fall zu Fall unterschiedlich. Ob 
man bei den Prozen, die trotz integriertem Speichercontroller kein ECC 
unterstützen, das mit einem externen Chipsatz nachrüsten kann, weiß ich 
nicht. Klingt aber eher unsinnig.

> Das würde auch erfordern, daß der Datenbus die Korrekturbits zusätzlich 
> überträgt. Tut er das?

Das kommt auf das Mainboard an. Mein mittelprächtiges Asus-Board (mit 
AMD Phenom II X4 drauf) hat die dafür notwendigen Leitungen. Manch 
Billig-Board nicht.

Hanno

[toc] | [prev] | [next] | [standalone]

#233668

On 10/14/2017 12:03 AM, Hans-Peter Diettrich wrote:
> Am 13.10.2017 um 15:40 schrieb Hanno Foest:
> 
>> Das ECC-RAM hat einfach mehr Bits als herkömmliches, die 
>> Auswertung/Korrektur passiert in dem Chip, der den Speicher verwaltet,
> 
> ACK
> 
>> also heutzutage direkt die CPU.
> 
> Das macht meist eine MMU bzw. Bridge-Chips, nicht die CPU.

Nein, bei AMD-CPUs ist das alles in der CPU integriert, die DIMMs hängen 
direkt an Pins der CPU. Auf dem Die findet man dann CPU(s), MMU, 
DRAM-Controller, Businterface...

Die Zeiten in denen sowas in der Bridge integriert war sind lange vorbei.

Andere machen das schon länger. Ich hab hier eine SUN Blade 1000 von 
2001, deren Datenbus zum RAM ist 288 Bit breit. Es werden immer 4 DIMMs 
mit 72Bit parallel angesprochen. Da wird wirklich alles per ECC abgesichert.


> Das würde auch erfordern, daß der Datenbus die Korrekturbits zusätzlich 
> überträgt. Tut er das?

Ja, natürlich. RAM mit ECC, aber Datenbus zwischen CPU und Northbridge 
ohne gabs zuletzt bei INTeL mit dem 440BX. Etwas hirntotes Design.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233632

Gerhard Hoffmann schrieb:
>
> Die Halbleiterhersteller kaufen die Keramikgehäuse vom Spezialisten.
> Die Wertschöpfung ist im Vergleich zum Chip selbst vernachlässigbar.
> Für Billigchips spendiert man gar nicht erst ein Keramikgehäuse.
> Man hat dann irgendwelche organische Pampe auf den Chip gepackt
> und gut war's, zumindest für langsame Alphateilchen.
> Gegen die schnellen in der kosmischen Strahlung hilft auch
> daumendickes Blei nix.

Das meinte man anfangs. Mittlerweile ist klar, dass die Neutronen
das Problem darstellen. Und da hilft Blei so wenig wie Alu, ausser
dass man natürlich mit Blei mehr Gramm in den Kubikzentimeter bringt.
Cadmium würde 1000x besser abschirmen, Gadolinium 10'000x.

> Überlege mal, wie Du so was überhaupt testen würdest. Kobaltquelle?
> Den PC zum Beschleuniger schleppen? Wüsstest DU, welche Zelle getroffen
> wird und könntest du verifizieren, was dann genau passieren muss
> und ob das auch passiert?

Wenn es sein muss, ja. Passiert im Bergwerk weniger? Auf dem Jungfraujoch
mehr? Ansonsten: Beschleuniger.
Bei Verstärkungseffekten können beliebig grosse Halbleiter nach einem
einzelnen Teilchentreffer kaputt gehen, GTOs etwa.
https://www.nzz.ch/article7B973-1.486122

-- 
mfg Rolf Bombach

[toc] | [prev] | [next] | [standalone]

#233487

On 10.10.17 20.39, Volker Borchert wrote:
> Man nimmt dabei an, daß die Wahrscheinlichkeiten für mehrere Kipper
> in ein und demselben Wort mit steigendes Anzahl so klein werden, daß
> die bei mehr als hd/2 theoretisch möglichen Falscherkennungen "nicht"
> vorkommen.

Ack. Selbst korrigierbare ECC Fehler sind außerordentlich selten. Ich 
habe es bei halbwegs aktueller Hardware bisher überhaupt nur ein 
einziges mal mit Rowhammer geschafft.


> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
> _kein_ ECC-DRAM verwenden sondern SRAM ;-)

Was sollte das bringen - außer mehr Kosten und Totalverlust bei leerer 
Batterie?

SRAM kippt auch, wenn es mit Alpha bestrahlt wird. Und da die Kipprate 
ganz wesentlich von der Chipfläche abhängt - ein Teilchen muss die Zelle 
nämlich erst mal /treffen/, ist SRAM sogar erst mal anfälliger. Das 
gleiche gilt für alte RAMs, die aufgrund der geringeren 
Integrationsdichte öfter mal "abgeschossen" werden. Natürlich ist die 
absolute Zahl der Bitkipper bei neuen RAMs nicht geringer, aber bezogen 
auf die einzelne Speicherzelle schon. Und nur letzteres ist für 
Fehlerkorrektur interessant.


Marcel

[toc] | [prev] | [next] | [standalone]

#233501

On 10/11/2017 02:04 PM, Marcel Mueller wrote:
> On 10.10.17 20.39, Volker Borchert wrote:
>> Man nimmt dabei an, daß die Wahrscheinlichkeiten für mehrere Kipper
>> in ein und demselben Wort mit steigendes Anzahl so klein werden, daß
>> die bei mehr als hd/2 theoretisch möglichen Falscherkennungen "nicht"
>> vorkommen.
> 
> Ack. Selbst korrigierbare ECC Fehler sind außerordentlich selten. Ich 
> habe es bei halbwegs aktueller Hardware bisher überhaupt nur ein 
> einziges mal mit Rowhammer geschafft.

Dann hattest du Glück... Wenn du genug Systeme am Laufen hast sieht das 
anders aus. Das schöne an ECC ist aber eben, daß du weisst, daß dein 
Speicher OK ist. Ohne ECC kannst du es nur hoffen. Ausserdem bekommst du 
es mit wenn der Speicher ein Problem entwickelt. Ohne ECC kann es bis du 
es merkst schon eine Menge Daten geschreddert haben.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233503

On 11.10.17 18.15, Gerrit Heitsch wrote:
> On 10/11/2017 02:04 PM, Marcel Mueller wrote:
>> Ack. Selbst korrigierbare ECC Fehler sind außerordentlich selten. Ich
>> habe es bei halbwegs aktueller Hardware bisher überhaupt nur ein
>> einziges mal mit Rowhammer geschafft.
>
> Dann hattest du Glück... Wenn du genug Systeme am Laufen hast sieht das
> anders aus. Das schöne an ECC ist aber eben, daß du weisst, daß dein
> Speicher OK ist. Ohne ECC kannst du es nur hoffen. Ausserdem bekommst du
> es mit wenn der Speicher ein Problem entwickelt. Ohne ECC kann es bis du
> es merkst schon eine Menge Daten geschreddert haben.

Ack.

Wobei im SOHO-Bereich der größte Nutzen von ECC ist, dass sich kein 
Händler traut, matschige Speicherbausteine mit ECC zu verkaufen. 
Schlicht deshalb, weil die mit nahezu 100% postwendend wieder auf dem 
Tisch liegen.
Das ist bei non-ECC leider anders. Rechner laufen mit defekten Speichern 
zuweilen erstaunlich lange ohne größere Auffälligkeiten. Da wird 
zuweilen der letzte RAMsch verkauft.


Marcel

[toc] | [prev] | [next] | [standalone]

#233508

On 10/11/2017 06:32 PM, Marcel Mueller wrote:
> On 11.10.17 18.15, Gerrit Heitsch wrote:
>> On 10/11/2017 02:04 PM, Marcel Mueller wrote:
>>> Ack. Selbst korrigierbare ECC Fehler sind außerordentlich selten. Ich
>>> habe es bei halbwegs aktueller Hardware bisher überhaupt nur ein
>>> einziges mal mit Rowhammer geschafft.
>>
>> Dann hattest du Glück... Wenn du genug Systeme am Laufen hast sieht das
>> anders aus. Das schöne an ECC ist aber eben, daß du weisst, daß dein
>> Speicher OK ist. Ohne ECC kannst du es nur hoffen. Ausserdem bekommst du
>> es mit wenn der Speicher ein Problem entwickelt. Ohne ECC kann es bis du
>> es merkst schon eine Menge Daten geschreddert haben.
> 
> Ack.
> 
> Wobei im SOHO-Bereich der größte Nutzen von ECC ist, dass sich kein 
> Händler traut, matschige Speicherbausteine mit ECC zu verkaufen. 

Das auch... die Wahrscheinlichkeit RAMsch zu bekommen ist ziemlich 
klein, man weiss es ja sofort. :)



> Das ist bei non-ECC leider anders. Rechner laufen mit defekten Speichern 
> zuweilen erstaunlich lange ohne größere Auffälligkeiten. Da wird 
> zuweilen der letzte RAMsch verkauft.

Dagegen kann man durchaus was machen... Kaufe kein RAM mit hübschen 
Kühlkörpern welche die ICs verdecken. Wenn das RAM was taugt braucht es 
keine Kühlung wenn man von sehr speziellem RAM absieht.

Kaufe kein RAM welches eine gegen über der Spec erhöhte Spannung braucht 
um sauber zu funktionieren. War bei DDR2 ziemlich schlimm.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#233525

On 11.10.17 19.00, Gerrit Heitsch wrote:
>> Das ist bei non-ECC leider anders. Rechner laufen mit defekten
>> Speichern zuweilen erstaunlich lange ohne größere Auffälligkeiten. Da
>> wird zuweilen der letzte RAMsch verkauft.
>
> Dagegen kann man durchaus was machen... Kaufe kein RAM mit hübschen
> Kühlkörpern welche die ICs verdecken. Wenn das RAM was taugt braucht es
> keine Kühlung wenn man von sehr speziellem RAM absieht.
>
> Kaufe kein RAM welches eine gegen über der Spec erhöhte Spannung braucht
> um sauber zu funktionieren. War bei DDR2 ziemlich schlimm.

Hinreichend ist das indes nichts.

Praktisch kaufe ich nur noch KVR. Das kostet nur unwesentlich mehr und 
hat Lifetime Warranty.


Marcel

[toc] | [prev] | [next] | [standalone]

#233662

On 2017-10-10, Volker Borchert <v_borchert@despammed.com> wrote:
> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
> _kein_ ECC-DRAM verwenden sondern SRAM ;-)

Die Freescale-CPUs, die wir im Netzwerkbereich einsetzen, haben selbst für
L1/L2-Cache ECC.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#233672

On 14.10.17 13.16, Michael Schwingen wrote:
> On 2017-10-10, Volker Borchert <v_borchert@despammed.com> wrote:
>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
>
> Die Freescale-CPUs, die wir im Netzwerkbereich einsetzen, haben selbst für
> L1/L2-Cache ECC.

Das haben AFAIK die meisten CPUs.


Marcel

[toc] | [prev] | [next] | [standalone]

#233674

On 2017-10-14, Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
>>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
>>
>> Die Freescale-CPUs, die wir im Netzwerkbereich einsetzen, haben selbst für
>> L1/L2-Cache ECC.
>
> Das haben AFAIK die meisten CPUs.

Ja.  Worauf ich hinauswollte: der Cache ist SRAM, kein DRAM, die Hersteller
sehen also Gründe dafür, auch SRAM nicht einfach so einzusetzen, sondern ECC
hinzuzufügen.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#233676

Michael Schwingen <news-1457978346@discworld.dascon.de> wrote:
> On 2017-10-10, Volker Borchert <v_borchert@despammed.com> wrote:
>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
> 
> Die Freescale-CPUs, die wir im Netzwerkbereich einsetzen, haben selbst für
> L1/L2-Cache ECC.
> 
Um das ganze etwas zu präzisieren: ja, es ist SRAM - alles andere ergäbe
für lokale Caches keinen Sinn - und ja, es wird ECC implementiert.

Denn auch SRAM kann Bitfehler produzieren, und gerade in den genannten
Anwendungsbereichen können solche höchst unschöne Folgen haben...

Gruß,
Florian

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web