Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Volker Borchert]

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>

 

[Gerhard Hoffmann]

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

 

[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?

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>

 

[Matthias Weingart]

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

 

[Matthias Weingart]

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

 

[Gerrit Heitsch]

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

 

[Hans-Peter Diettrich]

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

 

[Marcel Mueller]

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

 

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

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

 

[Gerrit Heitsch]

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

 

[Marcel Mueller]

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

 

[Gerrit Heitsch]

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

 

[Patrick Schaefer]

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

 

[Marcel Mueller]

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

 

[Rolf Bombach]

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

 

[Gerhard Hoffmann]

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

 

[Gerrit Heitsch]

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

 

[Hanno Foest]

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

 

[Gerhard Hoffmann]

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.

 

[Hanno Foest]

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