Workstation: erste Tests

Am 25.07.2023 um 20:45 schrieb Arno Welzel:

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

"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

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

Gerrit

Sebastian Suchanek schrieb:

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.

Helmut Schellong schrieb:

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.

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

Ja, das wird mir langsam klar.

Gerhard Hoffmann schrieb:

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.

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.

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.

Helmut Schellong schrieb:

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.

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

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

Viel Spaß damit :->

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

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

Für einen bloßen Vergleich von lediglich 33000 Dateien mit lächerlichen

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

Volker Bartheld schrieb:

Etwas langfädiger etwa hier:

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.

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

DoDi

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

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.

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

Am 26.07.23 um 14:53 schrieb Alexander Schreiber:

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

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.

Am 26.07.2023 um 12:09 schrieb Rolf Bombach:

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.

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

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

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

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

cu Michael

Am 26.07.2023 um 12:16 schrieb Rolf Bombach:

Siehe auch anderes Posting.

b)

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.

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

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:

cu Michael