Workstation: erste Tests

Am 25.07.2023 um 07:59 schrieb Arno Welzel:

Anders kann man auch nicht einen neuen Instruktionssatz breit durchsetzen. Diese Übersetzungen /on-the-fly/ sind hier vollkommen ungenügend.

Helmut Schellong schrieb:

Dir fehlt es ganz offensichtlich am Verständnis dessen, was dazu erforderlich wäre

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

Du bist doch überhaupt kein Ingenieur und warst es auch nie

Und angesichts deiner üblichen sinnfreien Behauptungen völlig unglaubwürdig

MfG Rupert

Nein, wie kommst Du denn darauf? Jede Instruktion ist n-fach vorhanden, mit genügend Register-Variationen. Es werden Adressen enthaltende Register für mem-Zugriff definiert. Konstanten werden mit bestimmten Instruktionen in Register geladen. Letztlich basiert alles auf Registern.

Wenn ein Index mit 12+12 Bits vorliegt, umfaßt dieser Index die Werte 0..(2^24)-1.

Es entsteht eine wohlstrukturierte homogene Liste. Jeder Compiler kann alles damit anfangen.

Geht nicht. Executables lassen sich nicht nennenswert komprimieren. Völlig ungenügend.

Am 25.07.2023 um 12:20 schrieb Rupert Haselbeck:

Offensichtlich? Was konkret liegt denn da offen?

Ich habe hier vor Wochen bewiesen, wie ich 110 GB Daten durchanalysiert hatte. Begleitet von Beschreibung, 6 Fotos und Multitasking-Shell-Skript.

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

Ich hatte mittels Arbeitszeugnis bewiesen, daß ich als "Entwicklungsingenieur" eingestellt wurde. Ich habe auch schon bewiesen, daß ich 6 Semester studiert hatte.

Ich habe nicht vor, dies nochmals zu beweisen.

Ich werden das hier nicht beweisen. Beweise sind hier überwiegend sinnfrei, denn sie werden entsprechend ignoriert oder lügnerisch als Fälschung hingestellt.

Thus spoke Helmut Schellong:

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

HTH,

Sebastian

Thus spoke Helmut Schellong:

Ja, Du hast den Allerlängsten hierzugroup. Das wolltest Du doch hören, oder?

Tschüs,

Sebastian

Am 25.07.2023 um 18:44 schrieb Sebastian Suchanek:

Das reicht ja auch. Warum? Weil es mit vereinzelten 1-Bit-Fehlern beginnt. Wenn so etwas im Log ist, macht man halt einen MemTest.

Ich brauche hin und wieder absolute Datenkorrektheit, ja. Gleichzeitig weiß ich, daß ich diese nicht garantiert bekommen kann. Es scheinen alle zu glauben, ich sei völlig unausgebildet. Hamming-Distanz, Parität, Reed Solomon, ..., lernte ich bereits vor Jahrzehnten! Sogar im Techniker-Kalender ist so etwas enthalten.

Helmut Schellong, 2023-07-25 11:45:

Ja, das habe ich implizit angenommen.

Eben - deswegen habe ich das nicht extra hingeschrieben.

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.

Eben - ein Hobby. Ist ja auch ok so. Aber das kannst Du doch auch einfach so sagen. Oder wäre das für Dich unehrenhaft, einfach sagen "weil es mit Spaß macht, egal ob man das unbedingt so braucht"?

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

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.

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

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.

Das macht die Verwendung von ECC nicht überflüssig - aber ECC ist eben auch nicht "automatisch Datenkorrektheit".

Helmut Schellong, 2023-07-25 19:54:

Und die gibt es eben nicht. Nur eine sehr hohe Wahrscheinlichkeit dafür.

Auch diese Verfahren sorgen nur dafür, dass die *Wahrscheinlichkeit* für unerkannte Fehler sinkt.

Um festzustellen, ob Daten wirklich *absolut* korrekt sind, müsste man den vollständigen Datensatz mit einem *bekannt* korrekten Original vergleichen. Sobald die Prüfsumme weniger Bits umfasst als die geprüften Daten, gibt es zwangsläufig Kollisionen in der Weise, dass es garantiert auch eine andere Bitfolge gibt, die zur selben Prüfsumme führt.

Ja, in der Praxis genügen Prüfsummen oft, weil Hardware nicht so fehleranfällig ist, dass ständig Fehler vorkommen und es eher selten ist, dass funktionierender RAM häufiger 2- oder 3-Bit-Fehler hat, wenn er nicht gerade auf mehreren tausend Meter Höhe betrieben wird.

Helmut Schellong, 2023-07-25 11:50:

Doch, hast Du - genau in dem Posting, was ich zitiert habe. Marc Haber hat überhaupt nichts von Caches geschrieben.

Kommt ein Patient zum Urologen. Er beklagt bitterlich die übermäßige Länge seines Geschlechts: "Herr Doktor, Herr Doktor, ich sags Ihnen: Gehe ich an den Strand und ziehe mich um. Bumms, liegt das Ding im Sand. Auf dem Volksfest, im Pissoir: Bumms, in der Rinne. Es ist schrecklich!".

Der Arzt bittet, der Patient möge sich untenrum freimachen. "Donnerlittchen!" entfährt es ihm. "Starkes Stück! Da müssen wir Schwester Elsa kommen lassen, über konkrete Maßnahmen möchte ich nur nach Konsultation des schönen Geschlechts entscheiden!".

Schwester Elsa kommt und betrachtet die Situation nachdenklich. Schließlich: "Herr Doktor, icke hab ne Idee. Ick gloobe, wir verlängern de Beene!".

Volker

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

Ja - *noch*.

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

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

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

Doch, sehr gut.

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

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

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

Am 25.07.2023 um 20:21 schrieb Arno Welzel:

Was immer wieder untergeht: DDR5 hat grundsätzlich ein eingebautes ECC. Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

Genau das wäre falsch - eine Verbrämung! Ich führe ja diejenige Arbeit weiter, die ich zuvor am Arbeitplatz erbrachte. Elektronik entwickeln und programmieren.

Mein alter PC von 2006 mußte nun durch etwas Modernes ersetzt werden. Das tat ich nach 17 Jahren. 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.

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. Dafür brauchte ich die Workstation nicht.

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.

Am 25.07.2023 um 20:32 schrieb Arno Welzel:

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.

Ich habe bereits mit memtest86+ geprüft.

Meistens ergibt sich aber doch Datenkorrektheit.

Du hast natürlich vollkommen recht, es /kann/ das alles geben. Das wäre dann ein System, das keinerlei 1-bit-Fehler aufweist, keine

Ich trage auf der Straße keinen Helm gegen Mikrometeoriten. Und ich habe nur ein einziges Ersatzrad im Auto.

Am 25.07.2023 um 20:38 schrieb Arno Welzel:

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.

Ein Test des gesamten RAM ist eine andere Operation.

Und das führt dazu, daß meistens tatsächliche Datenkorrektheit vorliegt.

Das ist eine problematische Formulierung. Sicher ist, daß bei 1 Bit weniger mit allerhöchster Wahrscheinlichkeit ein wirklich vollkommen anderer Hash entsteht. Eine Kollision liegt vor, wenn zwei (deutlich) unterschiedliche Dateien den gleichen Hash generieren.

Ein Hash kippt von Bit zu Bit auf einen vollkommen anderen Wert: SHA2-256 ("0") = 5feceb66ffc86f38d952786c6d696c79c2dbc239dd4e91b46729d73a27fb57e9 SHA2-256 ("1") = 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b SHA2-256 ("2") = d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35 SHA2-256 ("3") = 4e07408562bedb8b60ce05c1decfe3ad16b72230967de01f640b7e4729b49fce SHA3-256 ("0") = f9e2eaaa42d9fe9e558a9b8ef1bf366f190aacaa83bad2641ee106e9041096e4 SHA3-256 ("1") = 67b176705b46206614219f47a05aee7ae6a3edbe850bbbe214c536b989aea4d2

SHA3 ist der neue, wesentlich sicherere Keccak-Algorithmus.

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

Am 25.07.2023 um 20:39 schrieb Arno Welzel:

|Wenn Deine Weltsicht keine Zwischenstufe zwischen RAM und Registern |kennt, solltest Du Dir mal überlegen, welche Fortschritte das |CPU-Design in den letzten 30 Jahren gemacht hat.

Siehe hier oben.