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 1 of 2  [1] 2  Next page →

#233429 — Re: ECC-RAM

Michael Unger wrote:
> On 2017-10-06 14:46, "Frank Möller" wrote:
> 
> > [...]
> > 
> > [...]                                                         Aber nein,
> > ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er
> > existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_
> > es.
> 
> So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen
> _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig
> erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das
> mittlerweile geändert?

Kommt auf den Code an, Stichwort "Hamming-Distanz". Gängige Verfahren
mit (n+2) Prüfbits für (2^n) Nutzbits haben eine solche von 4, d.h.
beliebige zwei gültige Speicherworte unterscheiden sich an mindestens
4 Stellen. Bei zwei gekippten Bits kann man damit zwar noch erkennen,
daß dies der Fall ist, aber nicht mehr, von welcher Seite man kam.
Durch geeignete Prüfsummen erreicht man außerdem, daß jedes gültige
Speicherwort mindestens zwei Nullen und mindestens zwei Einsen enthält
und erkennt so außerdem "alles 0" oder "alles 1".

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.

So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter
zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau
beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand
gehabt oder waren sie Vaporware?

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

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [next] | [standalone]

#233432

On 10/10/2017 08:39 PM, Volker Borchert wrote:
> Michael Unger wrote:
>> On 2017-10-06 14:46, "Frank Möller" wrote:
>>
>>> [...]
>>>
>>> [...]                                                         Aber nein,
>>> ein RAM-Fehler kann _nicht_ "überall" stecken. Er steckt im RAM oder er
>>> existiert nicht. Ob er existiert, weißt Du halt nicht. Ich mit ECC _weiß_
>>> es.
>>
>> So wie ich das vor langer Zeit mal mitbekommen hatte, kann man einen
>> _einzelnen_ Bit-Fehler korrigieren und einen _doppelten_ zuverlässig
>> erkennen; darüber hinaus waren keine Aussagen mehr möglich. Hat sich das
>> mittlerweile geändert?
> 
> Kommt auf den Code an, Stichwort "Hamming-Distanz". Gängige Verfahren
> mit (n+2) Prüfbits für (2^n) Nutzbits haben eine solche von 4, d.h.
> beliebige zwei gültige Speicherworte unterscheiden sich an mindestens
> 4 Stellen. Bei zwei gekippten Bits kann man damit zwar noch erkennen,
> daß dies der Fall ist, aber nicht mehr, von welcher Seite man kam.
> Durch geeignete Prüfsummen erreicht man außerdem, daß jedes gültige
> Speicherwort mindestens zwei Nullen und mindestens zwei Einsen enthält
> und erkennt so außerdem "alles 0" oder "alles 1".

Es gibt auch ECC-Kodierungen die mehr können. Stichwort 'Chipkill'. 
Damit kannst du bis zu 4 defekte Bits erkennen und korrigieren und 8 
zuverlässig erkennen. Diese Stufe braucht man allerdings eher selten, 
NASA z.B.


> 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.

Bei 'Chipkill'-ECC wird davon ausgegangen, daß auch mal ein ganzer IC 
ausfallen kann und deshalb werden die ECC-Bits so verteilt, daß das 
System danach trotzdem noch funktioniert. Man könnte es als RAID5 fürs 
RAM bezeichnen. :)


> So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter
> zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau
> beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand
> gehabt oder waren sie Vaporware?

Ich kenne nur den 74LS688, aber das ist ein reiner Vergleicher, er sagt 
dir ob an den beiden 8Bit-Inputs dasselbe Bitmuster anliegt. Den gab es, 
ich hab ihn verbaut gesehen. Ist von der Funktion her identisch zum 74F521.

Typische Anwendung waren I/O-Karten bei denen man die Adresse per 
Software ändern konnte. So ziemlich jede Karte für den Amiga die dessen 
Autoconfig-Logik benutzte hatte einen 74LS688 oder 74F521 in der Schaltung.


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

SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und 
genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht 
es also auch bei SRAM nicht.

  Gerrit

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

#233456

In de.rec.fotografie, Gerrit Heitsch wrote:
> On 10/10/2017 08:39 PM, Volker Borchert wrote:
> 
> > So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter
> > zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau
> > beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand
> > gehabt oder waren sie Vaporware?
> 
> Ich kenne nur den 74LS688, aber das ist ein reiner Vergleicher,

Den kenn ich natürlich auch, müßten noch irgendwo ein paar herumliegen.

<databook vendor="TI" vintage="1985">

Ich meinte aber
630..631  error detection and correction 16 bit
632..633  error detection and correction 32 bit with byte write
634..635  error detection and correction 32 bit
636..637  error detection and correction 8 bit
insbesondere im Zusammenspiel mit
600..603  memory refresh controller
604..607  octal 2-input multiplexed registers
608       memory cycle controller
610..613  memory mappers

</>

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#233468

Gerrit Heitsch <gerrit@laosinh.s.bawue.de>:

> 
>> Ich hoffe trotzdem, daÇY Avionik, Medizintechnik und Kernkraftwerke
>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
> 
> SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und 
> genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht 
> es also auch bei SRAM nicht.

Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial 
kommen? (DRAM sicherlich mehr als SRAM).

M.
-- 

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

#233520

Am 11.10.2017 08:44 schrieb Matthias Weingart:

> Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial
> kommen? (DRAM sicherlich mehr als SRAM).

So ist es. Ich kann mich an einen Artikel aus den '80ern erinnern, in 
dem nachgewiesen wurde, dass Computer maximal 500k RAM haben dürfen um 
weniger als einen Bitkipper pro Tag zu haben.

IBM hat das zum Anlass genommen, um seinem PC (mit 64kB) und PC/XT (mit 
bis zu 640kB -- mehr braucht niemand ;-) Paritätsbits zu spendieren.


Zum Glück haben die RAM-Hersteller das Problem mit der 
256kbit-Chipgeneration in den Griff bekommen.


Patrick

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

#233526

Matthias Weingart schrieb:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de>:
>
>>
>>> Ich hoffe trotzdem, daÇY Avionik, Medizintechnik und Kernkraftwerke
>>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
>>
>> SRAM ist immer noch sehr teuer wenn man es mit DRAM vergleicht... und
>> genauso Hardware, auch dort sterben hin und wieder Zellen. Ohne ECC geht
>> es also auch bei SRAM nicht.
>
> Ist RAM nicht anfällig gegen Alphateilchen, die aus dem Gehäusematerial
> kommen? (DRAM sicherlich mehr als SRAM).

Heutige Gehäusematerialien sind speziell ausgesucht. Problem scheint
heute kosmische Strahlung zu sein.
https://en.wikipedia.org/wiki/Soft_error#Cosmic_rays_creating_energetic_neutrons_and_protons

Suche nach "bit flip cosmic ray" fördert einiges zutage, die Grenze
zur Verschwörungstheorie verschwimmt allerdings.

-- 
mfg Rolf Bombach

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

#233463

Am 10.10.2017 um 20:39 schrieb Volker Borchert:

> So wenigstens IIRC die Theorie. Siehe beispielsweise die Datenblätter
> zu den TTLs 74LS6xx von TI, da waren auch die Prüfsummenformeln genau
> beschrieben. Hat die eigentlich irgendjemand mal wirklich in der Hand
> gehabt oder waren sie Vaporware?

Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt.
War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als
echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik-
gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend-
welche Isotope in der Keramik, die Alphastrahlen verschossen haben.
(Kam später raus.)

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

SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst
ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch
größeres Ziel ab.

FPGAs speichern ihre Programmierung üblicherweise in einem riesigen
statischen RAM ab. Das macht ihre Benutzung in der Raumfahrt ziemlich
heikel. Man kann aber nicht darauf verzichten. Ich habe gerade ein
Projekt hinter mir, wo der Konfigurationsspeicher des FPGAs alle
halbe Minuten neu aus einem Rom geladen wurde. Die Benutzerlogik,
also das, was das FPGA wirklich tun soll, war dann dreifach redundant,
in der Hoffnung, dass es in der halben Minute nicht 2 Nachbarn mit
gleicher Funktion trifft.

Das Nachladen wurde vom FPGA selbst gesteuert. Das ist dann so, als
ob man selber den Teppich austauscht auf dem man steht. Oder, als ob
man sich selbst operiert und sein eigenes Gehirn gegen ein Backup
austauscht. Das krankste, was ich jemals habe bauen müssen.

Wenn man das alles richtig und bewiesen hat, kann immer noch der
Spannungsregler einen "single event upset" bekommen. Der ist dann
für eine Millisekunde besinnungslos und dreht so lange ganz auf oder
ganz zu. Der Rest des Reglers muss das abkönnen ohne daß was abkocht.

Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
das Problem ist, als dessen Lösung es gilt. Wenn man etwas in den
Weltraum schießt, dann muss man wegen der dortigen Strahlenbelastung
eben durch und muss beweisen, dass das auch funktioniert.

Unter meinem Schreibtisch würde ein China-Motherboard mit ECC-Feature
eher keine Heimat finden.


Gruß, Gerhard

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

#233464

In de.rec.fotografie, Gerhard Hoffmann wrote:
> Am 10.10.2017 um 20:39 schrieb Volker Borchert:
> 
> > Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
> > _kein_ ECC-DRAM verwenden sondern SRAM ;-)
> 
> SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst
> ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch
> größeres Ziel ab.

Ist der kontinuierliche Stromfluß einer SRAM Zelle wirklich genauso
empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert
(Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger)
Elektronen eines DRAM-Kondensators?

Verblüfft

	vb


-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#233472

On 10/11/2017 05:15 AM, Volker Borchert wrote:
> In de.rec.fotografie, Gerhard Hoffmann wrote:
>> Am 10.10.2017 um 20:39 schrieb Volker Borchert:
>>
>>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
>>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
>>
>> SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst
>> ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch
>> größeres Ziel ab.
> 
> Ist der kontinuierliche Stromfluß einer SRAM Zelle wirklich genauso
> empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert
> (Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger)
> Elektronen eines DRAM-Kondensators?

Eine SRAM-Zelle in CMOS (keiner baut was anderes mehr) hat keinen 
kontinuierlichen Stromfluss. Das gabs nur bei NMOS. Ansonsten könntest 
du ein SRAM nicht über Jahre mit einer kleinen Batterie puffern.

  Gerrit

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

#233484

Am 11.10.2017 um 05:15 schrieb Volker Borchert:
> In de.rec.fotografie, Gerhard Hoffmann wrote:
>> Am 10.10.2017 um 20:39 schrieb Volker Borchert:
>>
>>> Ich hoffe trotzdem, daß Avionik, Medizintechnik und Kernkraftwerke
>>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
>>
>> SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst
>> ihren Inhalt. Sie enthält mehr Transistoren, also gibt sie ein noch
>> größeres Ziel ab.
> 
> Ist der kontinuierliche Stromfluß einer SRAM Zelle wirklich genauso
> empfindlich gegen vorbeiknallende Strahlung wie die wenigen hundert
> (Aussage des Dozenten 1987 - heute vermutlich noch deutlich weniger)
> Elektronen eines DRAM-Kondensators?

IMO kommt es da auf die Einschlagstelle an. Ein Flipflop aus mehrern 
Transistoren mußte eigentlich wegen der Rückkopplung unempfindlicher 
sein, wenn nur 1 Transistor getroffen wird.

Wirkt sich Strahlung auf alle Speicherzellen gleich aus, oder nur auf 
die mit dem "falschen" (empfindlichen...) Zustand? Kippt die Strahlung 
das getroffene Bit, oder versetzt sie es in nur in einen 
konstruktionsspezifischen Default (T/F) Zustand?

DoDi

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

#233469

Gerhard Hoffmann <gerhard@hoffmann-hochfrequenz.de>:

>> Ich hoffe trotzdem, daÇY Avionik, Medizintechnik und Kernkraftwerke
>> _kein_ ECC-DRAM verwenden sondern SRAM ;-)
> 
> SRAM ist keinen Deut besser. Eine Zelle, die getroffen wird, vergisst
> ihren Inhalt. Sie enthÇÏlt mehr Transistoren, also gibt sie ein noch
> grÇôÇYeres Ziel ab.
 
Wir hatten mal eine CPU die holte ihren Code nur aus dem doppelt 
knopfzellengepufferten SRAM. Da hatte ich sicherheitshalber ne 
Prüfsummencheck über den Programmcode gebastelt. Wie sich später rausstellte 
sehr sinnvoll. Die Mitteilung "program error" kam recht zuverlässig nach fast 
jedem Transatlantikflug (ob nun von der Höhenstrahlung oder den 
Gepäckscannern, keine Ahnung), zumindest ein Bit im 32kByte Code-Bereich war 
da gekippt.
Der vorsorglich gebastelte Kunden-Updater über die RS232 mit einem PC 
Programm wurde dann plötzlich sehr wichtig ;-).

M.
-- 

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

#233493

Am 11.10.2017 um 02:59 schrieb Gerhard Hoffmann:

> Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt.
> War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als
> echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik-
> gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend-
> welche Isotope in der Keramik, die Alphastrahlen verschossen haben.
> (Kam später raus.)

Soweit ich mich erinnere, waren diese Keramikgehäuse aber eine 
Siemens-Spezialität.

> Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
> das Problem ist, als dessen Lösung es gilt.

Erzähl doch bitte mal, das klingt interessant.

> Wenn man etwas in den
> Weltraum schießt, dann muss man wegen der dortigen Strahlenbelastung
> eben durch und muss beweisen, dass das auch funktioniert.

Ich seh jetzt gerade keinen so ganz großen Unterschied, ob du den 
Speicher nachlädst oder korrigierst. Meinem Bauchgefühl nach scheint mir 
das vom FPGA selbst gesteuerte Nachladen anfälliger zu sein - wie gehst 
du mit Bitkippern in dem Bereich, der für die Nachlademimik zuständig 
ist, um?

> Unter meinem Schreibtisch würde ein China-Motherboard mit ECC-Feature
> eher keine Heimat finden.

Auch hier würde mich die Begründung interessieren.

Ich habe zwei (!) Mal kaputtes RAM gehabt, was zu seltenen Crashes und 
kaputten Daten geführt hat. Nachdem irgendwelche Checksummen von Dateien 
nicht stimmten, war der Fall klar, aber memtest hat trotzdem noch 18 
Stunden gebraucht, um mir Fehler zu zeigen. Sowas wollte ich nie wieder, 
entsprechend werkelt hier jetzt ECC-RAM unter meinem Schreibtisch. Daß 
es wirklich funktioniert, und das Mapping der RAM-Sockel auf die 
Vorstellungen meines Betriebssystems, hab ich ausprobiert, indem ich mit 
einem an 0 Volt angeschlossenen Widerstand am Speicher rumgeprokelt habe 
-> haufenweise Fehler angezeigt / korrigiert.

Im Betrieb hab ich in den letzten 5? Jahren dann nur einen Fehler geloggt.

Hanno

PS. de.rec.fotografie? Ich leite mal zu de.sci.el um...

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

#233567

Am 11.10.2017 um 15:09 schrieb Hanno Foest:
> Am 11.10.2017 um 02:59 schrieb Gerhard Hoffmann:
> 
>> Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt.
>> War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als
>> echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik-
>> gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend-
>> welche Isotope in der Keramik, die Alphastrahlen verschossen haben.
>> (Kam später raus.)
> 
> Soweit ich mich erinnere, waren diese Keramikgehäuse aber eine 
> Siemens-Spezialität.

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.

> 
>> Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
>> das Problem ist, als dessen Lösung es gilt.
> 
> Erzähl doch bitte mal, das klingt interessant.

Ü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?
Teststrukturen einbauen verHeisenbugt die Schaltung.
(Observing it affects the outcome)
Die Parity über 32+n oder gar 64+n Bits auszurechnen erfordert
komplexe Gatter mit entsprechend vielen Eingängen; die Korrektur
nochmal. Da sind schnell ein paar Takte vergangen bis die Daten
tatsächlich der CPU zur Verfügung stehen. Weil die CPU-Performance
hauptsächlich von der Speicherbandbreite abhängt, verführt das
natürlich zu Kreativität beim Hochpushen des Taktes.
Das Gewissen wird dabei nur mäßig beansprucht, man hat ja ECC.

Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
und das lief alles nicht stabil. Nur das Speichertestprogramm, das
dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
und der Z80 hatte nur 7. Das dauernde Umpflügen des Speichers hat
das geschickt verdeckt. Auch ein Heisenbug.
Das war unangenehm, da war schon für die ganze Serie eingekauft.


> Ich seh jetzt gerade keinen so ganz großen Unterschied, ob du den 
> Speicher nachlädst oder korrigierst. Meinem Bauchgefühl nach scheint mir 
> das vom FPGA selbst gesteuerte Nachladen anfälliger zu sein - wie gehst 
> du mit Bitkippern in dem Bereich, der für die Nachlademimik zuständig 
> ist, um?

Das Konfigurationsram des FPGAs kann man nicht korrigieren, das
ist im Chip drinnen. Es ist nicht völlig unmöglich, das Ram auch
wieder auszulesen, aber die Daten enthalten auch don't-care-Stellen
und man braucht ein Maskenfile um nur die tatsächlich vorhandenen
Bits zu betrachten. Wo soll man das nun wieder strahlungsfest
aufheben? Da ist es einfacher, jede Minute das RAM aus einem
strahlungsfesten ROM einfach nachzuladen.

Das geht im Prinzip wie das Booten des FPGAs aus dem ROM, man muss
nur rechtzeitig den Ladetakt stoppen, bevor das FPGA sein globales
Reset am Ende der Ladesequenz aktiviert. Dann wäre nämlich der
Zustand der Benutzer-Schaltung futsch. Wenn man alles richtig
macht, ist das für die Funktionaltät auf Benutzerebene völlig
transparent. Man nennt den Vorgang Scrubben.

Nun ja, nicht völlig transparent. Es gibt im Xilinx Virtex
die Möglichkeit, einen Logikblock statt als Gatter lieber
als 16-Bit-Ram zu benutzen. Das ist in Wirklichkeit ein kleines
Fenster ins Konfigurationsram. Man ahnt schon, was passiert,
wenn man das Konfigurationsram alle Minuten in seinen Grund-
zustand zurücksetzt.

Meine Software-Kollegin hat sich beschwert, dass ihre Register
eine Vorliebe für bestimmte Werte entwickelt haben, wenn man sie
lange genug in Ruhe gelassen hat.(die Register).
Kurz, man darf diese Ramblöcke in einem gescrubbten System nicht
verwenden. Unglücklicherweise benutzt der Picoblaze-Prozessor das
für seine Register. Ich durfte also den Picoblaze umbauen, dass
er nur D-Flipflops benutzt hat. Das war eigentlich recht simpel.
Nebenbei hat es bewiesen, dass das Nachladen funktioniert.  1/2 :-)

Die Nachladelogik ist im Benutzerland von genau dem FPGA, das
nachgeladen wird. Wenn sie getroffen würde, wäre das Spiel aus,
der Inhalt des Konfigurationsspeichers würde ganz langsam
vergammeln.

Deshalb wird alles, was wichtig ist 3-fach redundant ausgeführt.
Jedes FlipFlop, jedes Gatter. Alles ist streng synchron.
In jedem Takt werden die 3 FlipFlops miteinander verglichen.
Wenn eins abweicht, wird es als falsch angesehen und statt dessen
die Mehrheitsmeinung benutzt. Nach dem nächsten Takt ist die Welt
dann wieder in Ordnung.

Dem FPGA-Compiler ist das alles ein Graus. Er stellt umgehend
fest, dass er 2/3 der Logik einsparen kann und dass trotzdem
das gleiche rauskommt. Das ist ihm erstaunlich schwer abzu-
gewöhnen. Der wichtigste Trick dagegen waren je 3 Input-Pins für
True und False. Die wurden ausserhalb des Chips fest mit 0 oder
3.3V verbunden. Das hat man dem Compiler aber nicht verraten.
Optimierungsversuche liefen deshalb ins Leere.

Ich habe mir eine schöne Bibliothek gemacht, die von oben
wie standard_logic / sl_vector aussieht und die Verdreifachung
und die Abstimmung über die Resultate fast völlig verbirgt.
Es gibt auch von Xilinx ein Tool dafür, das gilt aber rechtlich
als Kriegswaffe und darf nicht aus den USA exportiert werden.



> 
>> Unter meinem Schreibtisch würde ein China-Motherboard mit ECC-Feature
>> eher keine Heimat finden.
> 
> Auch hier würde mich die Begründung interessieren
> 
> Ich habe zwei (!) Mal kaputtes RAM gehabt, was zu seltenen Crashes und 
> kaputten Daten geführt hat. Nachdem irgendwelche Checksummen von Dateien 
> nicht stimmten, war der Fall klar, aber memtest hat trotzdem noch 18 
> Stunden gebraucht, um mir Fehler zu zeigen. Sowas wollte ich nie wieder, 
> entsprechend werkelt hier jetzt ECC-RAM unter meinem Schreibtisch. Daß 
> es wirklich funktioniert, und das Mapping der RAM-Sockel auf die 
> Vorstellungen meines Betriebssystems, hab ich ausprobiert, indem ich mit 
> einem an 0 Volt angeschlossenen Widerstand am Speicher rumgeprokelt habe 
> -> haufenweise Fehler angezeigt / korrigiert.
> 
> Im Betrieb hab ich in den letzten 5? Jahren dann nur einen Fehler geloggt.

Ja, genau.

Ich glaube nicht, dass einer der China-Hersteller seinen Krempel
jemals zu einem Beschleuniger geschleppt hat.

Da kaufe ich lieber ordentlichen Speicher und verzichte
auf hochgeschraubtes Timing.
Mit einem Crash alle 5 Jahre kann ich leben.

Gruß, Gerhard

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

#233569

On 10/12/2017 09:49 PM, Gerhard Hoffmann wrote:
> Am 11.10.2017 um 15:09 schrieb Hanno Foest:
>> Am 11.10.2017 um 02:59 schrieb Gerhard Hoffmann:
>>
>>> Ich habe das schon mal zu 80386-Zeiten auf einer Multibus-Karte benutzt.
>>> War aber WIMRE in meinem Fall Intel oder Fairchild. Das war damals, als
>>> echte Panik aufkam wegen Bitkippern in RAMs in den edlen Keramik-
>>> gehäusen. Plastikgehäuse waren eher nicht betroffen, es waren irgend-
>>> welche Isotope in der Keramik, die Alphastrahlen verschossen haben.
>>> (Kam später raus.)
>>
>> Soweit ich mich erinnere, waren diese Keramikgehäuse aber eine 
>> Siemens-Spezialität.
> 
> 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.

Auch bei teuren tut man das nur, wenn man muss, weil z.B. sonst die 
Wärmeableitung nicht reicht. Wenn man nicht muss wird der Kram in Epoxy 
eingegossen. Ok, am Anfang gab es da Probleme mit, aber das ist lange her.



>>> Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
>>> das Problem ist, als dessen Lösung es gilt.
>>
>> Erzähl doch bitte mal, das klingt interessant.
> 
> Ü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?
> Teststrukturen einbauen verHeisenbugt die Schaltung.
> (Observing it affects the outcome)
> Die Parity über 32+n oder gar 64+n Bits auszurechnen erfordert
> komplexe Gatter mit entsprechend vielen Eingängen; die Korrektur
> nochmal. Da sind schnell ein paar Takte vergangen bis die Daten
> tatsächlich der CPU zur Verfügung stehen. Weil die CPU-Performance
> hauptsächlich von der Speicherbandbreite abhängt, verführt das
> natürlich zu Kreativität beim Hochpushen des Taktes.
> Das Gewissen wird dabei nur mäßig beansprucht, man hat ja ECC.

Macht aber nichts weil typischerweise zuerst Einzel- oder Zweibitfehler 
auftreten wenn man es übertreibt und die werden von ECC erkannt, bei 
hohen Anforderungen auch mehr. Da merkt man gleich, daß man Mist gebaut hat.

Heutiges ECC findet direkt im DRAM-Controller statt, da ist nichts mehr 
mit 'mehreren Takten' die über die Latenzen die das RAM sowieso schon 
hat rausgehen.



> Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
> kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
> und das lief alles nicht stabil. Nur das Speichertestprogramm, das
> dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
> und der Z80 hatte nur 7. Das dauernde Umpflügen des Speichers hat
> das geschickt verdeckt. Auch ein Heisenbug.

Nein, das war kein Heisenbug, das war jemand der vergessen hat 
Datenblätter zu lesen bevor er einkauft. Da steht nämlich drin welchen 
Refresh die DRAMs brauchen. Das der Z80 nur einen 7Bit-Refreshzähler hat 
darf als bekannt vorausgesetzt werden.

Und der Schreiber der DRAM-Testroutine hat ebenso was übersehen... 
Nämlich, daß jeder Lesezugriff bei einem DRAM ein Rrefresh ist. Wenn du 
also DRAM korrekt testen willst musst du sicherstellen, daß dein 
Testprogramm das korrekt tut, also genug Zeit ohne Zugriffe verstreichen 
lassen, damit sich fehlender Refresh bemerkbar macht. Kann man auch 
hinbekommen wenn das Programm im zu testenden RAM läuft.


> Das war unangenehm, da war schon für die ganze Serie eingekauft.

Braucht ein paar Gatter zusätzlich, dann hat man den 8Bit-Refresh. Oder 
man löst es per Software (wenn man die CPU-Zeit dafür hat).



> Meine Software-Kollegin hat sich beschwert, dass ihre Register
> eine Vorliebe für bestimmte Werte entwickelt haben, wenn man sie
> lange genug in Ruhe gelassen hat.(die Register).

Kann bei SRAM passieren.


> 
> Da kaufe ich lieber ordentlichen Speicher und verzichte
> auf hochgeschraubtes Timing.

Woher weisst du das der Speicher ordentlich ist? Auch beim besten 
Hersteller kommen Fehler vor. Hanno beschrieb einen Bug für den er 18 
Stunden brauchte bevor er mit memtest einen Fehler bekam. Eigentlich 
sehr ordentlicher Speicher wenn du die Fehlerrate in 10^-x ausdrückst...


> Mit einem Crash alle 5 Jahre kann ich leben.

Du weisst aber nicht was in der Zeit alles an Bitkippern passiert ist 
die nicht zu einem Crash führten und wieviele Dateien jetzt streng 
genommen kaputt sind. Das ist das Problem ohne ECC, du weisst nicht ob 
dein RAM OK ist, du kannst es nur hoffen.

In einer Mediendatei stört ein gekipptes Bit meist nicht wirklich. In 
einem Excel-Sheet hingegen kann es eine Formel oder einen Wert verändern 
und drastische Auswirkungen haben.

Du hast überall ECC oder zumindest Prüfsummen im Rechner. Festplatten 
und SSDs würden ohne ECC gar nicht mehr funktionieren. Der Cache in 
deiner CPU benutzt ECC (beim P2/Celeron konnte man das noch im BIOS 
abschalten), PCI-Express benutzt CRC für den Datentransfer, kein 
TCP-Paket geht ohne Checksumme auf die Reise... Aber beim RAM soll man 
darauf vertrauen, daß schon alles gutgehen wird? Komische Sichtweise.

  Gerrit

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

#233640

Am 12.10.2017 um 22:25 schrieb Gerrit Heitsch:
> On 10/12/2017 09:49 PM, Gerhard Hoffmann wrote:

>> Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
>> kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
>> und das lief alles nicht stabil. Nur das Speichertestprogramm, das
>> dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
>> und der Z80 hatte nur 7. Das dauernde Umpflügen des Speichers hat
>> das geschickt verdeckt. Auch ein Heisenbug.
> 
> Nein, das war kein Heisenbug, das war jemand der vergessen hat 
> Datenblätter zu lesen bevor er einkauft. 

Daß das System defekt war, was ja von Anfang an klar. Und was der
Designer falsch gemacht hat ist auch egal. Aber wenn das
Testprogramm das Verhalten des Objektes verändert, dann ist das
genau die Heisenbug-Definition.

Das kam übrigens raus im Gespräch von Kunde zu Kunde am
Ladenschalter von Distron in Berlin..


>> Meine Software-Kollegin hat sich beschwert, dass ihre Register
>> eine Vorliebe für bestimmte Werte entwickelt haben, wenn man sie
>> lange genug in Ruhe gelassen hat.(die Register).
> 
> Kann bei SRAM passieren.

Nein, kann bei SRAMs nicht passieren, es sei denn, sie sind kaputt.
Das zyklische Nachladen des Konfigurationsspeichers hat die Raminhalte
alle paar Sekunden auf den Wert aus dem ROM zurückgesetzt.

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

#233669

On 10/14/2017 12:42 AM, Gerhard Hoffmann wrote:
> Am 12.10.2017 um 22:25 schrieb Gerrit Heitsch:
>> On 10/12/2017 09:49 PM, Gerhard Hoffmann wrote:
> 
>>> Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
>>> kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
>>> und das lief alles nicht stabil. Nur das Speichertestprogramm, das
>>> dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
>>> und der Z80 hatte nur 7. Das dauernde Umpflügen des Speichers hat
>>> das geschickt verdeckt. Auch ein Heisenbug.
>>
>> Nein, das war kein Heisenbug, das war jemand der vergessen hat 
>> Datenblätter zu lesen bevor er einkauft. 
> 
> Daß das System defekt war, was ja von Anfang an klar. Und was der
> Designer falsch gemacht hat ist auch egal. Aber wenn das
> Testprogramm das Verhalten des Objektes verändert, dann ist das
> genau die Heisenbug-Definition.

Das Testprogramm war aber defekt weil es eben gewisse Eigenschaften von 
DRAMs nicht in Betracht gezogen hat. Hätte es das getan wäre der Bug 
gleich aufgefallen. Das ist kein Heisenbug, das ist einfach ein defektes 
Testprogramm und jemand der beim Design des Systems die Datenblätter 
nicht gelesen hat. Zwei Fehler auf einmal also und deren 
Wechselwirkungen sind nicht mehr vorhersehbar.


> Das kam übrigens raus im Gespräch von Kunde zu Kunde am
> Ladenschalter von Distron in Berlin..

Aha... Also Datenblatt nicht gelesen.


> 
> 
>>> Meine Software-Kollegin hat sich beschwert, dass ihre Register
>>> eine Vorliebe für bestimmte Werte entwickelt haben, wenn man sie
>>> lange genug in Ruhe gelassen hat.(die Register).
>>
>> Kann bei SRAM passieren.
> 
> Nein, kann bei SRAMs nicht passieren, es sei denn, sie sind kaputt.

Doch, das kann bei SRAM passieren. Wenn da eine Zelle lange einen immer 
gleichen Wert enthält kann sie eine Vorliebe für diesen Wert entwickeln 
und den schon beim Einschalten haben. Was hingegen nicht passieren darf 
ist das sich Werte die man dort einmal eingespeichert hat ohne 
Schreibzugriff ändern. Wenn sie das tun ist das RAM schlicht defekt und 
auszutauschen.

  Gerrit

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

#233611

Am 12.10.2017 um 21:49 schrieb Gerhard Hoffmann:

>> Soweit ich mich erinnere, waren diese Keramikgehäuse aber eine 
>> Siemens-Spezialität.
> 
> Die Halbleiterhersteller kaufen die Keramikgehäuse vom Spezialisten.
> Die Wertschöpfung ist im Vergleich zum Chip selbst vernachlässigbar.

Klar, aber irgendwie war mir noch im Gedächtnis, daß das nur Siemens 
diesbezüglich auffällig gewesen ist. Warum auch immer. Mag mich auch irren.

>>> Bei ECC kann man dermaßen viel falsch machen, dass es für mich eher
>>> das Problem ist, als dessen Lösung es gilt.
>>
>> Erzähl doch bitte mal, das klingt interessant.
> 
> Überlege mal, wie Du so was überhaupt testen würdest.

Ich hatte das beschrieben, weiter unten steht noch das Originalzitat. 
Das ECC-RAM hat einfach mehr Bits als herkömmliches, die 
Auswertung/Korrektur passiert in dem Chip, der den Speicher verwaltet, 
also heutzutage direkt die CPU. Wenn du jetzt also irgendwie am Datenbus 
des Speichers elektrisch rumprokelst, so daß es (einige, aber nicht zu 
viele) falsche Bits gibt, dann sollte sich bei geeigneter Konfiguraton 
das OS nachdrücklich darüber beschweren.

> Kobaltquelle? Den PC zum Beschleuniger schleppen?

Kann man machen, wenn man gerne naturnah erzeugte Fehler haben möchte. 
Oder man legt ein Stückchen Radium auf die DIMMs. - Hmm, ich hab noch 
Thorium-haltige Glühstrümpfe. Was bei meinen russischen 
Mantelrohr-Geigerzählern Ereignisse auslöst, sollte auch für RAM 
reichen... mal ausprobieren :)

Wer es gerne weniger ionisierend hätte, kann auch einfach mit einer 
Wärmelampe auf die RAMs zielen. Laut einem Paper, das quasi die 
Vorarbeit zum Rowhammer-Exploit ist, erhöht das die Fehlerhäufigkeit 
beträchtlich. Ist ja auch plausibel.

> Wüsstest DU, welche Zelle getroffen
> wird und könntest du verifizieren, was dann genau passieren muss
> und ob das auch passiert?

Das RAM ist für mich eine Black Box. Wenn nicht die gleichen Bits 
rauskommen wie reingehen, festgestellt durch die ECC-Prüffunktion, ist 
das nicht gut (tm). Wie und warum die Bits genau falsch sind, kann mir 
egal sein. Ohne ECC stürzt der Rechner bei Fehlern auf dem Datenbus 
instantan ab, mit ECC nicht, aber er beschwert sich. Das entspricht der 
Theorie und insofern kann der konkrete Aufbau schon mal nicht so ganz 
falsch sein.

> Weil du oben Siemens-Rams erwähnt hast: Ich habe mal jemanden
> kennengelernt, der hatte Siemens-64K-Rams in seiner Z80-Konstruktion
> und das lief alles nicht stabil. Nur das Speichertestprogramm, das
> dann aber beliebig lange. Ja, die Rams brauchten 8-Bit-Refreshadressen
> und der Z80 hatte nur 7.

Altbekanntes Problem... die Speicher mit 8-Bit-Refresh gab es dann 
billiger :)

[...]
> Die Nachladelogik ist im Benutzerland von genau dem FPGA, das
> nachgeladen wird. Wenn sie getroffen würde, wäre das Spiel aus,
> der Inhalt des Konfigurationsspeichers würde ganz langsam
> vergammeln.
> 
> Deshalb wird alles, was wichtig ist 3-fach redundant ausgeführt.
> Jedes FlipFlop, jedes Gatter. Alles ist streng synchron.
> In jedem Takt werden die 3 FlipFlops miteinander verglichen.
> Wenn eins abweicht, wird es als falsch angesehen und statt dessen
> die Mehrheitsmeinung benutzt. Nach dem nächsten Takt ist die Welt
> dann wieder in Ordnung.

Interessantes Projekt. Hoffentlich hast du keine SPOF-Bits übersehen. 
Weisstschon, Komplexität... und wie hast du das eigentlich getestet? 
Kobaltquelle? Linearbeschleuniger? :)

>> Ich habe zwei (!) Mal kaputtes RAM gehabt, was zu seltenen Crashes und 
>> kaputten Daten geführt hat. Nachdem irgendwelche Checksummen von 
>> Dateien nicht stimmten, war der Fall klar, aber memtest hat trotzdem 
>> noch 18 Stunden gebraucht, um mir Fehler zu zeigen. Sowas wollte ich 
>> nie wieder, entsprechend werkelt hier jetzt ECC-RAM unter meinem 
>> Schreibtisch. Daß es wirklich funktioniert, und das Mapping der 
>> RAM-Sockel auf die Vorstellungen meines Betriebssystems, hab ich 
>> ausprobiert, indem ich mit einem an 0 Volt angeschlossenen Widerstand 
>> am Speicher rumgeprokelt habe -> haufenweise Fehler angezeigt / 
>> korrigiert.
>>
>> Im Betrieb hab ich in den letzten 5? Jahren dann nur einen Fehler 
>> geloggt.
> 
> Ja, genau.
> 
> Ich glaube nicht, dass einer der China-Hersteller seinen Krempel
> jemals zu einem Beschleuniger geschleppt hat.

Wie beschrieben - meiner Meinung nach nicht notwendig. Bitfehler ist 
Bitfehler.

> Da kaufe ich lieber ordentlichen Speicher und verzichte
> auf hochgeschraubtes Timing.
> Mit einem Crash alle 5 Jahre kann ich leben.

Der Bitfehler wird dir mit einiger Wahrscheinlichkeit (Verhältnis 
Daten/Code) eher deine Daten versauen als denen Rechner crashen, so war 
es ja auch bei mir. Und selbst wenn dann daemon xy segfaultet, weißt du 
immer noch nicht, ob es an der Hardware oder Software liegt. Ob und wann 
du merkst, daß dein Speicher gurkig ist und deine Daten im Arsch sind, 
bleibt dem Zufall überlassen - selbst wenn du "guten" Speicher bekommen 
hast und man dich nicht über den Tisch gezogen hat, kann es sein, daß er 
mit der Zeit Fehler entwickelt, so war es ja auch bei mir.

ECC zeigt dir, daß der Speicher OK ist. Die Wahrscheinlichkeit, daß ECC 
nach meinem Test nicht das tut, wozu es da ist, halte ich für sehr 
gering. Deutlich geringer jedenfalls als die Wahrscheinlichkeit, daß RAM 
kaputtgeht.

Hanno

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

#233620

Am 13.10.2017 um 15:40 schrieb Hanno Foest:
> Am 12.10.2017 um 21:49 schrieb Gerhard Hoffmann:

> [...]
>> Die Nachladelogik ist im Benutzerland von genau dem FPGA, das
>> nachgeladen wird. Wenn sie getroffen würde, wäre das Spiel aus,
>> der Inhalt des Konfigurationsspeichers würde ganz langsam
>> vergammeln.
>>
>> Deshalb wird alles, was wichtig ist 3-fach redundant ausgeführt.
>> Jedes FlipFlop, jedes Gatter. Alles ist streng synchron.
>> In jedem Takt werden die 3 FlipFlops miteinander verglichen.
>> Wenn eins abweicht, wird es als falsch angesehen und statt dessen
>> die Mehrheitsmeinung benutzt. Nach dem nächsten Takt ist die Welt
>> dann wieder in Ordnung.
> 
> Interessantes Projekt. Hoffentlich hast du keine SPOF-Bits übersehen. 
> Weisstschon, Komplexität... und wie hast du das eigentlich getestet? 
> Kobaltquelle? Linearbeschleuniger? :)

Modelsim. Da kann man nach Herzenslust Fehler in die Userschaltung
injizieren. Es ist schon lustig zu sehen, wenn man bei einem 32-Bit-
Zähler in jedem Takt ein paar Bits kaputt macht und der läuft einfach
weiter, als ob nix wäre. Man kommt sich vor, als ob man mit einem
MG auf einen Terminator schießt, und der ignoriert das nicht mal.

Man kann auch über das CLB-Ram-Misfeature den Konfigurationsspeicher
ändern und dann zusehen, wie der Scrubber das wieder heilt.

Und single points of failure gibt es immer noch genug. Die Reset/
PowerUp-Logik des FPGAs  z.B. ist Hardware, und man kommt nicht dran.
Aber gegen die Millionen Konfigurationsbits im RAM ist das ein Klacks.

Das Power supply ist z.B. ein single point of failure.
Und so ein Reglerchip ist auch nicht immun.
Aus dem Datenblatt eines Radiation Hardened Exemplars:
< 
https://www.flickr.com/photos/137684711@N07/37415366000/in/dateposted-public/ 
  >

Aber irgendwo ist Schluss.

Auf der ISS wohnen letztlich Leute, soo schlimm ist es dort noch nicht.
Tamagotchis für die Kinder von Fukushima wäre wohl was anderes.

Ich habe aber z.B. einen schnellen JFET-OpAmp nicht bekommen, weil
niemand die Strahlungstests machen & dokumentieren wollte. Da musste
ich dann diskrete JFETs nehmen & eine Krücke drumrumbauen.



>>> Ich habe zwei (!) Mal kaputtes RAM gehabt, was zu seltenen Crashes 
>>> und kaputten Daten geführt hat. Nachdem irgendwelche Checksummen von 
>>> Dateien nicht stimmten, war der Fall klar, aber memtest hat trotzdem 
>>> noch 18 Stunden gebraucht, um mir Fehler zu zeigen. Sowas wollte ich 
>>> nie wieder, entsprechend werkelt hier jetzt ECC-RAM unter meinem 
>
> Der Bitfehler wird dir mit einiger Wahrscheinlichkeit (Verhältnis 
> Daten/Code) eher deine Daten versauen als denen Rechner crashen, so war 
> es ja auch bei mir. Und selbst wenn dann daemon xy segfaultet, weißt du 

Die meisten Speicherzugriffe sind Code, weil jeder Befehl seinen
Opcode braucht, aber bei weitem nicht jeder Befehl greift auf Daten im
Speicher zu. Hat der Cache, der 99% aller Zugriffe abwickelt auch ECC?

Mit meinen Rechnern bin ich sehr zufrieden.

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

#233622

Am 13.10.2017 um 17:07 schrieb Gerhard Hoffmann:

>> Interessantes Projekt. Hoffentlich hast du keine SPOF-Bits übersehen. 
>> Weisstschon, Komplexität... und wie hast du das eigentlich getestet? 
>> Kobaltquelle? Linearbeschleuniger? :)
> 
> Modelsim. Da kann man nach Herzenslust Fehler in die Userschaltung
> injizieren.

Sicher nicht schlecht, aber ich würde es trotzdem noch mal mit echter 
ionisierender Strahlung probieren. Vielleicht gibt es Überraschungen. 
("Das beste Modell für eine Katze ist eine Katze. Möglichst dieselbe 
Katze." - Norbert Wiener)

> Das Power supply ist z.B. ein single point of failure.
> Und so ein Reglerchip ist auch nicht immun. 

Das wissen Raspberry Pi 2 User spätestens, seit sie mal versucht haben, 
den laufenden Rechner mit Blitzlicht zu fotografieren :)

>> Der Bitfehler wird dir mit einiger Wahrscheinlichkeit (Verhältnis 
>> Daten/Code) eher deine Daten versauen als denen Rechner crashen, so 
>> war es ja auch bei mir. Und selbst wenn dann daemon xy segfaultet, 
>> weißt du 
> 
> Die meisten Speicherzugriffe sind Code, weil jeder Befehl seinen
> Opcode braucht, aber bei weitem nicht jeder Befehl greift auf Daten im
> Speicher zu.

Irrelevant. Bei Von-Neumann-Architektur liegen Daten und Code im 
gleichen Speicher, und in erster Näherung haben alle dessen 
Speicherzellen die gleiche Wahrscheinlichkeit, durch ionisierende 
Strahlung einen mitzubekommen. Wenn mehr Daten als Code im Speicher 
sind, trifft ein solches Ereignis entsprechend eher Daten als Code. Ob, 
wann und wie oft man die Daten dann abholt ist erst mal egal.

> 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.

> Mit meinen Rechnern bin ich sehr zufrieden.

Einzelfehler würdest du ja auch nicht mitbekommen. Ignorance is bliss :)

Hanno

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

#233641

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.


>> 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!

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web