Workstation: erste Tests...

[Helmut Schellong]

Am 25.07.2023 um 20:43 schrieb Arno Welzel:

Helmut Schellong, 2023-07-23 00:01:

Am 22.07.2023 um 21:43 schrieb Hanno Foest:
Am 22.07.23 um 20:32 schrieb Helmut Schellong:

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt, gewissermaßen hängen will.

Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc. Prozessoren, Intel investiert massiv
in RISC-V.

Dennoch ist x86 nach wie vor sehr beherrschend.

Ja - *noch*.

Bei Smartphones war x86 noch nie relevant und bei Apple auch nicht mehr.

Apple war doch erst bei IBM, dann bei Intel, nun bei ARM.

Die ersten Server auf Basis von ARM sind auch schon im Einsatz, z.B. mit
Ampere Altra:

https://www.deltacomputer.com/server/standardserver/ampere-altra.html

Es ist nur noch eine Frage der Zeit, bis x86 verschwindet.

Es erscheint so: man kann nicht davon lassen, man kann nicht, es geht einfach nicht,
es kann keinen Übergang zu etwas anderem geben, ...

Doch, sehr gut.

Ich meine Intel.

x86 ist ein sehr alter Instruktionssatz, vom 8086, 16 Bit, DOS, aus den 1970ern.
Übrigens ein längenatmender Instruktionssatz, der angeblich so ungefähr das Blödeste ist, was
man sich antun kann.

Deswegen arbeiten ja etliche Firmen daran, davon wegzukommen - inklusive
Microsoft:

https://support.microsoft.com/de-de/windows/h%C3%A4ufig-gestellte-fragen-zu-windows-arm-basierten-pcs-477f51df-2e3b-f68f-31b0-06f5e4f8ebb5

Das alles bestätigt Rolf Bombach und mich ja.
Wir beklagen, daß die Single-Thread-Performance in 15 Jahren nur aufs 2-fache stieg.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 25.07.2023 um 20:45 schrieb Arno Welzel:

Helmut Schellong, 2023-07-25 12:22:

Am 25.07.2023 um 10:41 schrieb Hans-Peter Diettrich:
[...]
Wenn schon, dann ein leistungsfähigeres Komprimierungsverfahren.


Geht nicht.
Executables lassen sich nicht nennenswert komprimieren.

Nicht? Komisch - hier lassen sich Binaries oft um Faktor 2-4
komprimieren. Da muss dann ja reichlich \"Luft\" vorhanden sein statt
echtem Code

Ja, ist so, man sollte Executables auch /strippen/.
Es können mitunter auch sehr viele Textteile darin sein, als Konstanten.
Kann auch sein, daß 64Bit-Exe besser komprimierbar sind.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Gerrit Heitsch]

On 7/25/23 20:32, Arno Welzel wrote:

Helmut Schellong, 2023-07-25 12:49:

Am 25.07.2023 um 12:20 schrieb Rupert Haselbeck:
Helmut Schellong schrieb:
[...]
Der Prozessor verlangt zwingend ECC+Registered RAM.
Da heraus ergibt sich automatisch Datenkorrektheit.

Nein, das ist natürlich falsch. ECC-RAM führt lediglich zu einer (bedeutenden) Verringerung der
Wahrscheinlichkeit von unentdeckten Fehlern im RAM - nicht mehr und nicht weniger

Diese Deine Behauptung ist natürlich falsch.
Aufgetretene ECC-Fehler bleiben nicht unbekannt.
Hingegen ohne ECC bleiben alle RAM-Fehler unbekannt.

Daraus ergibt sich aber keine absolute Datenkorrektheit. Es treten nur
deutlich *weniger* Fehler auf, die unerkannt bleiben. Dennoch können
bestimmte Fehler immer noch unerkannt bleiben - deren Auftreten ist nur
deutlich unwahrscheinlicher.

Mit ECC-RAM hast du eine garantierte Korrektur von Einbitfehlern und
eine garantierte Erkennung von Zweibitfehlern (die ergeben dann
üblicherweise eine System panic). Und das ist die einfache Form von ECC,
es gibt noch komplexere.

Es bräuchte also drei gekippte Bits im selben \'Wort\' damit das unerkannt
bleibt. Die Wahrscheinlichkeit dafür ist deutlich kleiner als die für
die Fehler, die ECC erkennen kann.

Gerrit

 

[Thomas Prufer]

On Tue, 25 Jul 2023 22:45:30 +0200, Helmut Schellong <var@schellong.biz> wrote:

Diese Formulierung ist nicht optimal und kann zu Mißverständnissen führen.
Bei mir gibt es die absolute Datenkorrektheit während gewisser Zeitspannen tatsächlich.

Wenn ich zwei große identische Testläufe mache und die Resultatdateien 8 MB
sind vollkommen identisch und mit plausiblem Inhalt, dann ist das ein Beweis, daß
diese Tests ohne Datenfehler abliefen.

\"Diese Formulierung ist nicht optimal und kann zu Mißverständnissen führen...\"

In der Sache haben das wohl alle verstanden. Ich jedenfalls sehe da eine
eigenwillige Definitionen von \"absolut\" und \"Beweis\", die von der allgemein
üblichen abweicht...

Ich mein das mit dem Beweis hatten wir schonmal?


Thomas Prufer

 

[Gerrit Heitsch]

On 7/25/23 22:45, Helmut Schellong wrote:

Wann immer es geht, verwende ich das Kommando \'cmp\'.
Das prüft alle Bytes auf Gleichheit.

\'diff -r\' ist auch nützlich wenn man ganze Verzeichnisbäume auf
Gleichheit überprüfen will.

Gerrit

 

[Rolf Bombach]

Sebastian Suchanek schrieb:

Bevor jemand im Vorbeigehen das noch glaubt:
ECC kann 1-Bit-Fehler erkennen und korrigieren. 2-Bit-Fehler
werden erkannt, können aber nicht mehr korrigiert werden.
Fehler, die 3 und mehr Bit betreffen, werden nur noch unter
bestimmten Umständen erkannt.

Soviel zum Thema (absolute) \"Datenkorrektheit\".

Und dann noch bei DDR5, die haben OCECC oder wie das heisst.
Was kontrolliert jetzt ECC? Error checking of the error checker?

BTW, es ist ja umstritten, ob DDR5 was bringt, wenn man
mehr als zwei Riegel verwendet, kann aber auch UL/FOAF sein.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Helmut Schellong schrieb:

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.

Jetzt musst du dich nur noch fragen, warum da freiwillig ein ECC
eingebaut ist. a) weil wir so lieb zu unseren Kunden sind und
nur ihr bestes wollen, oder b) das Memory ist mittlerweile
so überzüchtet, dass es ohne gar nicht mehr verkauft werden kann,
da peinlich viele Fehler entstehen.

Nunja, Harddisks sind seit Jahren wenn nicht Jahrzehnten
auf diesem Terrain.

> Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

Da muss man sich fragen, was dieses dann eigentlich genau
tut. Fehler der Fehlerkorrektur finden? Geht das überhaupt?

Eine Workstation ist ein typisches Ingenieur-Gerät!

Ja, das wird mir langsam klar.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Gerhard Hoffmann schrieb:

Als der 200 MHz pentium+ rauskam, da hatte es sich innerhalb
eines knappen Jahres ausge-alphat. Der Hammer, wenn man FPGAs
zu routen hatte.

https://de.wikipedia.org/wiki/Alpha-Prozessor

Alphas gab es mit > 1 GHz, darum wundert mich die Aussage etwas.
Bezüglich Floating Point hatten die noch eine Zeit lang die
Nase vorn. Genaues hab ich nicht so mitgekriegt, da ich bei
den Abgängern lag, die _nicht_ bei DEC landeten :-].

Jedenfalls war es die Zeit, als DEC im fat-dumb-happy-Modus
war und Intel nicht ernst genommen hat. Begonnen hat das
schon mit dem 80486. O-Ton: Ein Beinchen mit 33 MHz zappeln
lassen kann jeder. Das Management war total unfähig, insbesondere
auch was Marktanalysen betrifft. Und dann die Flops a la
Rainbow.

TI 99K, Clipper, Zilog, Sparc, Mips auch, mit unterschiedlichen
Siechtumsdauern. Wobei, der MIPS4000 hat mir gefallen.

Die Revolutionäre von Gestern sind die Reaktionäre von Heute.
Intel, selber eher etwas glücklos im Design, hat einfach
stur weitergemacht. Selbst Cray hat es eiskalt erwischt,
ungefähr beim Pentium III. PC = Personal Cray.

Ein seltenes Beispiel für eine schleichenden Disruption.

Das existiert längst als Hardware für on-the-fly. Aktuelle x86-
Prozessoren sind intern schon sooo lange RISCs mit hunderten von
Renaming-Registern.

Ich weiss auch nicht, ob DEC es mit dem RISC einfach übertrieben hat.
Also Microcode ist des Teufels und der Compiler muss es richten.

Mit der Technologiestufe ändert sich meist auch der Flaschenhals.
Zu jener Zeit grassierte ja noch der Wahn, wir werden alle im
von-Neumann-Flaschenhals stecken bleiben.

--
mfg Rolf Bombach

 

[Rupert Haselbeck]

Helmut Schellong schrieb:

Arno Welzel:
Ein AMD Ryzen aus der 5000er- oder 7000er-Reihe mit B550 oder X750
Chipsatz kann auch ECC. Ist halt nicht so teuer und man kann damit nicht
angeben - aber schlechter als mit einem Xeon ist das auch nicht, was die
Fehlerkorrektur betrifft.

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.

Ja. Warum wohl? Weil die Strukturen auf den DRAM-Chips so klein geworden
sind, dass verstärkt Fehler auftreten. Daher die On-Die-ECC bei DDR5.
Dieses \"eingebaute ECC\" arbeitet lediglich auf Die-Ebene und ist von
außen auch nicht sichtbar.

> Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

\"Registered\" hat mit Fehlerkorrektur überhaupt nichts zu tun - was es
bedeutet, kannst du bei Gelegenheit mal bei Wikipedia oder so nachlesen...
Und das, was du für \"zusätzliches äußeres ECC\" zu halten beliebst, ist
das, was tatsächlich die einzige Instanz ist, welche (die meisten)
Fehler auf den Datenleitungen auf RAM-Modulen und Mainboard, in
Speichercontroller und CPU-Speicherinterface zu erkennen vermag.

Mein alter PC von 2006 mußte nun durch etwas Modernes ersetzt werden.
Das tat ich nach 17 Jahren.

Und hast das Teil um ein Vielfaches überdimensioniert. Das zeigt
jedenfalls, dass du auch davon nicht sonderlich Ahnung hast. Wer würde
ansonsten derart viel Geld zum Fenster hinaus werfen, wenn er keinerlei
sinnvolle Verwendung dafür hat

Es erschent so, als ob so mancher nicht damit klarkommt - seltsam.
Das, was ich nun habe, ist nach vielen Jahren die erste HEDT-Plattform.
Und die habe ich mir eben geschnappt.

Viel Spaß damit :->

Ich habe aber auch kürzlich für eine Firma in Augsburg
als Entwicklungsingenieur in Rente gearbeitet - mit Versteuerung des
Einkommens.
Völlig normal - und staatlich erwünscht!

Das ist doch schön für Dich. Ich frage mich nur, was man da so konkret
tut, was zwingend so eine Hardware voraussetzt. Aber für Hobbies kann
man auch beliebig überdimensionierte Dinge anschaffen, die man
eigentlich nie wirklich *braucht*.

Ich habe da Software entwickelt, um die Daten einer alten Datenbank
auf eine moderne Datenbank transportieren zu können.
Kundenstrukturen von etwa 3500 Kunden waren darunter.

Also ein einfaches Shell-Skript, welches den Job auf jedem PC von der
Stange für 350Euro erledigen kann.

> Dafür brauchte ich die Workstation nicht.

Aber auf der \"Workstation\" wär das bestimmt in 3,5 statt 7,5 Sekunden
gelaufen

Es macht halt Spaß. Aber dass Dir etwas einfach Spaß macht, würdest Du
wohl nie zugeben. Nein, es muss begründet werden mit sachlichen
Anforderungen.

Ich habe vor einigen Wochen 33000 Dateien im Umfang von 110 GB analysiert
und bestimmte Daten mit Suchmustern herausgefiltert, mit einem
Multitasking-Shell-Skript.
DAFÜR und für Ahnliches brauche ich die Workstation.

Für einen bloßen Vergleich von lediglich 33000 Dateien mit lächerlichen
110GB braucht es sicher keinen Monsterrechner, wie du ihn beschrieben
hast. Auch das schafft locker der PC für 350 Euro. Der braucht dann halt
ein paar Minuten, wenn er nicht mit einer vernünftigen SSD und mit zu
wenig RAM ausgestattet ist. Als CPU genügt die billigste, welche zu
haben ist.

Aber du brauchst ja auch niemandem zu begründen, warum du dein Geld für
so ein Spielzeug ausgibst. Andere kaufen sich andere völlig unsinnige
bzw. überflüssige Dinge und freuen sich darüber. Das kann man ebenfalls
belächeln, aber es geht dennoch keinen was an!

Wer freilich ernsthaft vorgeben möchte, dass er, als Rentner, aus
vermeintlich rein rationalen Gründen solche Monsterspielzeuge anschafft,
der muss sich über Hohn und Spott nicht sonderlich wundern

MfG
Rupert

 

[Rolf Bombach]

Volker Bartheld schrieb:

Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege. Nicht, daß das für mich jetzt groß ein Problem
darstellen würde, weil ich Apple-Produkte selbst mit der Zange nicht
anfasse und für Experimente mit Raspberry Pi OS oder dem ROCK 5 Model B
nicht experimentierfreudig genug bin.

Etwas langfädiger etwa hier:

https://www.youtube.com/watch?v=Hjb3bx6vxnc&t=17s

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 26.07.2023 um 06:48 schrieb Gerrit Heitsch:

On 7/25/23 22:45, Helmut Schellong wrote:

Wann immer es geht, verwende ich das Kommando \'cmp\'.
Das prüft alle Bytes auf Gleichheit.

\'diff -r\' ist auch nützlich wenn man ganze Verzeichnisbäume auf Gleichheit überprüfen will.

Ja, es gibt unter Unix viele Wege, auf Gleichheit zu prüfen.

Bespielweise auch \'rsync\' oder
find /dir1 -type f -exec cmp [-o] {} /dir2/$(basename {}) || echo ERR {} \\;

Die find-Zeile ist allerdings unausgegoren, müßte geprüft werden: man find; man cmp.
Ein Shell-Skript ist immer am universellsten.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Gerrit Heitsch]

On 7/26/23 13:54, Helmut Schellong wrote:

Am 26.07.2023 um 06:48 schrieb Gerrit Heitsch:
On 7/25/23 22:45, Helmut Schellong wrote:

Wann immer es geht, verwende ich das Kommando \'cmp\'.
Das prüft alle Bytes auf Gleichheit.

\'diff -r\' ist auch nützlich wenn man ganze Verzeichnisbäume auf
Gleichheit überprüfen will.

Ja, es gibt unter Unix viele Wege, auf Gleichheit zu prüfen.

Bespielweise auch \'rsync\' oder
find /dir1 -type f -exec cmp [-o] {} /dir2/$(basename {}) || echo ERR {} \\;

Solche Konstrukte sind nett, aber man muss aufpassen, bei Dateinamen mit
SPACE (was man vermeiden sollte) passieren oft überraschende Dinge wenn
man vergisst an passenden Stellen Quotes zu verwenden.

Gerrit

 

[Alexander Schreiber]

Helmut Schellong <var@schellong.biz> wrote:

Am 25.07.2023 um 20:21 schrieb Arno Welzel:
Helmut Schellong, 2023-07-25 11:45:

Am 25.07.2023 um 07:52 schrieb Arno Welzel:
Helmut Schellong, 2023-07-18 11:35:

Am 18.07.2023 um 09:58 schrieb Marc Haber:
Helmut Schellong <var@schellong.biz> wrote:
Bei der Konzeption der WS habe ich offenbar alles sehr richtig gemacht.

Bis auf die Bedarfsbestimmung.

Das ist ein Irrtum.
Ich arbeite recht viel wissenschaftlich, analytisch, testend, untersuchend.
Ich benötige absolute Datenkorrektheit, wenn ich 100 GB durchanalysiere.

Und wieso glaubst Du, dass die nicht gegeben ist, wenn die Hardware kein
Xeon 3435X mit 128 RAM ist?

Verstehe ich nicht.
RAM 128 GB bewirkt doch keine Datenkorrektheit.
Hingegen ECC bewirkt Datenkorrektheit.

Ja, das habe ich implizit angenommen.

Der Prozessor verlangt zwingend ECC+Registered RAM.

Eben - deswegen habe ich das nicht extra hingeschrieben.

Da heraus ergibt sich automatisch Datenkorrektheit.

Guter Witz übrigens. ECC hilft, Fehler zu erkennen und gegebenenfalls
(nicht immer!) zu korrigieren. Einzelbitfehler sind häufig (und können
mit ECC korrigiert werden - aber wenn das zuviele sind, kann das durchaus
beeindruckend viel Speicherbandbreite fressen (BTST)). Für Datenkorrekt-
heit müsste man _wesentlich_ mehr Aufwand treiben, zum Beispiel alle
Datenpfade und Speicher dreifach[0] auslegen, mit Vergleichlogik dazu.
Wird teuer und komplex, macht keiner.

Ein AMD Ryzen aus der 5000er- oder 7000er-Reihe mit B550 oder X750
Chipsatz kann auch ECC. Ist halt nicht so teuer und man kann damit nicht
angeben - aber schlechter als mit einem Xeon ist das auch nicht, was die
Fehlerkorrektur betrifft.

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.

Und das ist kein positives Hervorhebungsmerkmal, sondern einfach nur ein
pragmatisches Eingeständnis, dass _ohne_ chip-level ECC der DDR5 Speicher
allenfalls als lausiger Zufallswertgenerator funktioniert. Was man da
aus dem Speicher rausliest hätte ohne diese ECC allenfalls nur eine ganz
grobe Korrelation mit vorher reingeschriebenen Werten.

Man liest sich,
Alex.
[0] zweifach reicht wenn \"rote Lampe anmachen und System stoppen\"
akzeptabel ist
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison

 

[Hanno Foest]

Am 26.07.23 um 14:53 schrieb Alexander Schreiber:

Guter Witz übrigens. ECC hilft, Fehler zu erkennen und gegebenenfalls
(nicht immer!) zu korrigieren. Einzelbitfehler sind häufig (und können
mit ECC korrigiert werden - aber wenn das zuviele sind, kann das durchaus
beeindruckend viel Speicherbandbreite fressen (BTST)).

Ich konnte mal einen Blick auf einen Server mit schweren
Speicherproblemen werfen, der loggte ECC Fehler mit maximaler Lograte.
War aber dennoch gut benutzbar. Die Kollegen hatten Nerven: Die haben
mit dem Speichertausch bis zum nächsten Wartungsfenster gewartet.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Helmut Schellong]

Am 26.07.2023 um 06:46 schrieb Thomas Prufer:

On Tue, 25 Jul 2023 22:45:30 +0200, Helmut Schellong <var@schellong.biz> wrote:


Diese Formulierung ist nicht optimal und kann zu Mißverständnissen führen.
Bei mir gibt es die absolute Datenkorrektheit während gewisser Zeitspannen tatsächlich.

Wenn ich zwei große identische Testläufe mache und die Resultatdateien 8 MB
sind vollkommen identisch und mit plausiblem Inhalt, dann ist das ein Beweis, daß
diese Tests ohne Datenfehler abliefen.


\"Diese Formulierung ist nicht optimal und kann zu Mißverständnissen führen...\"

In der Sache haben das wohl alle verstanden. Ich jedenfalls sehe da eine
eigenwillige Definitionen von \"absolut\" und \"Beweis\", die von der allgemein
üblichen abweicht...

Ich mein das mit dem Beweis hatten wir schonmal?

Niemand hat bisher hier im Kontext \'absolut\' und \'Beweis\' genau definiert.
Meine Aussage oben ist gewiß nicht 100% astrein und unmißverständlich.
Das geht mit 3 Zeilen einfach nicht.
Sie ist an der Praxis orientiert.

Ein Hash mit sha256 oder sha512 ist auch nicht ein /totaler/ Beweis.
Trotzdem tun gewöhnlich alle so.
Es könnte ja der gelieferte gleiche Hash _unberechtigt_ gleich sein!

Ein Hash ist eine Zahl z.B. im Wertebereich 0..(2^256)-1.
Die Anzahl möglicher verschiedener Dateien ist jedoch unendlich viel größer!
Eine Datei kann 1 TeraBit Datenmenge umfassen.
Dieser Dateiinhalt kann als eine Dualzahl betrachtet werden.
Wertebereich 0..(2^(10^12))-1.
Soviel verschiedene Dateien mit je 1 TeraBit Länge kann es geben.
Wenn nun eine Datei mit 1 Bit mehr betrachtet wird:
Wertebereich 0..(2^(10^12+1))-1.
Usw.
Dafür können doch gar nicht genügend _unterschiedliche_ Hashes generiert werden!
Folglich sind Kollisionen unvermeidlich.
Diejenigen, die sha512 entwickelten, wissen das, und sie wissen, daß die Menge
der verschiedenen Hashes hier größer ist als bei sha256, wodurch die Sicherheit steigt.
Trotz allem kann es durch Hashes niemals eine Garantie geben!
Das ist jedoch Theorie.
In der Praxis kann es Hashes mit einer Trillion Bit Länge nicht geben.
Dennoch arbeiten /alle/ mit Hashes 256 Bit - ist halt sicher genug.

|Wenn ich zwei große identische Testläufe mache und die Resultatdateien 8 MB
|sind vollkommen identisch und mit plausiblem Inhalt, dann ist das ein Beweis, daß
|diese Tests ohne Datenfehler abliefen.

Ein wirklicher theoretisch-mathematischer Beweis liegt vorstehend nicht vor.
Jedoch _gilt_ Vorstehendes in der Praxis als - Praxis-Beweis.

Ich weiß konkret aus der Praxis, wie RAM-Fehler sich zeigen.
Es fängt klein an - steigert sich aber, bis es unübersehbar ist.
Mir wurde solch ein Vorgang berichtet, 2 Monate nach ersten Anzeichen.
Vor Ort sah ich an der Charakteristik, daß es hochwahrscheinlich RAM-Fehler sind.
\'memtest86\' bestätigte meinen Verdacht.
Es waren mindestens Megabyte an RAM defekt, von 24 GB.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 26.07.2023 um 12:09 schrieb Rolf Bombach:

Sebastian Suchanek schrieb:

Bevor jemand im Vorbeigehen das noch glaubt:
ECC kann 1-Bit-Fehler erkennen und korrigieren. 2-Bit-Fehler
werden erkannt, können aber nicht mehr korrigiert werden.
Fehler, die 3 und mehr Bit betreffen, werden nur noch unter
bestimmten Umständen erkannt.

Soviel zum Thema (absolute) \"Datenkorrektheit\".

Und dann noch bei DDR5, die haben OCECC oder wie das heisst.
Was kontrolliert jetzt ECC? Error checking of the error checker?

Hatte ich hier vor kurzem beschrieben.
Das nennt sich On-Die-ECC, und repariert 1-Bit-Fehler OnDie, ohne daß das nach außen dringt.

BTW, es ist ja umstritten, ob DDR5 was bringt, wenn man
mehr als zwei Riegel verwendet, kann aber auch UL/FOAF sein.

Schneller ist DDR5 sowieso.
Wohl deshalb hat DDR5 überhaupt ODECC.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Michael Schwingen]

On 2023-07-25, Helmut Schellong <var@schellong.biz> wrote:

Ja, eine Garantie für absolute Datenkorrektheit gibt es nicht - eine Binsenweisheit.
Schrieb ich auch zuvor an Sebastian Suchanek.
In den weitaus meisten Fällen wird aber durch ECC eine vollkommene Datenkorrektheit
faktisch erreicht.

\"in den meisten Fällen\" und \"vollkommene Datenkorrektheit\" schließt sich
aus. Wenn die Daten nur in den meisten Fällen stimmen, ist das nicht
vollkommen.

> Ich habe bereits mit memtest86+ geprüft.

Du kannst mit einem Test die Abwesenheit von seltenen Fehlern nicht
beweisen.

> Meistens ergibt sich aber doch Datenkorrektheit.

Eben, Du reduzierst die Fehlerwahrscheinlichkeit (deutlich). Mehr nicht.

cu
Michael
--
Some people have no respect of age unless it is bottled.

 

[Helmut Schellong]

Am 26.07.2023 um 12:16 schrieb Rolf Bombach:

Helmut Schellong schrieb:

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.

Jetzt musst du dich nur noch fragen, warum da freiwillig ein ECC
eingebaut ist. a) weil wir so lieb zu unseren Kunden sind und
nur ihr bestes wollen, oder b) das Memory ist mittlerweile
so überzüchtet, dass es ohne gar nicht mehr verkauft werden kann,
da peinlich viele Fehler entstehen.

Siehe auch anderes Posting.

b)

Nunja, Harddisks sind seit Jahren wenn nicht Jahrzehnten
auf diesem Terrain.

Ja, ich lese da seit Äonen Reed Solomon, und sie tauschen korrekte Blöcke gegen defekte ein.
Aussortierte HDD bei mir hatten auch nie defekte Daten transportiert, sie wurden stark langsamer.

Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

Da muss man sich fragen, was dieses dann eigentlich genau
tut. Fehler der Fehlerkorrektur finden? Geht das überhaupt?

Das innere ODECC arbeitet vollkommen getrennt.
Es repariert 1-Bit-Fehler.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Michael Schwingen]

On 2023-07-26, Rupert Haselbeck <mein-rest-muell@gmx.de> wrote:

Was immer wieder untergeht:
DDR5 hat grundsätzlich ein eingebautes ECC.

Ja. Warum wohl? Weil die Strukturen auf den DRAM-Chips so klein geworden
sind, dass verstärkt Fehler auftreten. Daher die On-Die-ECC bei DDR5.
Dieses \"eingebaute ECC\" arbeitet lediglich auf Die-Ebene und ist von
außen auch nicht sichtbar.

Ja. Und obwohl Rowhammer IIRC zu DDR3-Zeiten entdeckt wurde, ist DDR4 und
DDR5 soweit ich weiss immer noch betroffen.

Und: auch ECC schützt nicht:

https://www.vusec.net/projects/eccploit/

So viel zum Thema \"absolute Korrektheit der Daten durch ECC\" ;-)

cu
Michael
--
Some people have no respect of age unless it is bottled.

 

[Hans-Peter Diettrich]

On 7/26/23 6:45 AM, Gerrit Heitsch wrote:

Mit ECC-RAM hast du eine garantierte Korrektur von Einbitfehlern und
eine garantierte Erkennung von Zweibitfehlern (die ergeben dann
üblicherweise eine System panic). Und das ist die einfache Form von ECC,
es gibt noch komplexere.

Es bräuchte also drei gekippte Bits im selben \'Wort\' damit das unerkannt
bleibt.

Das stimmt so nicht. Bei mehr als 2 falschen Bits *kann* es passieren,
daß ein Fehler unerkannt bleibt, in ziemlich seltenen Fällen.

DoDi