Workstation: erste Tests

Am 26.07.2023 um 13:00 schrieb Rupert Haselbeck:

Ja, weiß ich seit 2022, seit mein neuer PC feststand.

Brauche ich nicht, weiß ich seit vielleicht 10 Jahren.

Die Attribute meiner RAM-Riegel lauten halt: Registered, ECC.

Ja.

Ich wollte so etwas wie SkylakeX oder CascadeLake (HEDT), kam aber nicht. Es kam nur die Workstation /Sapphire Rapids/, die oberhalb einer Mainstream-Plattform liegt.

Nein, der Auftraggeber erhielt ein kommando.exe für Windows von mir. Die Grundlage sind große binäre Datenbank-Dateien.

Ich hätte die Aufgabe auch per bish-Skript lösen können. Für mich selbst - nicht jedoch für meinen Auftraggeber. Ich konnte so auch mehr Honorar verlangen.

Ja, aber der Auftraggeber hat bei sich das kommando.exe laufen lassen.

Ein PC für 350 EUR würde wohl nicht ein paar Minuten, sondern eher Stunden benötigen. (Meine Festplatten kosten bereits 900 EUR.) Ich habe mehrfach dargestellt, daß die Workstation in der Regel etwa 50-fach schneller ist, als meine alte Plattform mit E8600 3333 MHz.

Ich wollte halt einen PC, der über Mainstream liegt, nach 17 Jahren mit der alten Plattform. Meine Gründe sind überwiegend rational.

Ja, das sowieso; jedoch ich selbst produziere niemals Dateinamen mit enthaltenen SPACEs. Fremde Dateien werden von mir auch entsprechend eingepflegt (oft ganz anderer Name). Und der OS-Hersteller verwendet ebenso niemals SPACEs in Dateinamen.

Konstruktionen, die Bestand haben (Skript, Alias), versehe ich dennoch stets mit maskierenden Einfassungen.

Kein Witz. Ich habe 'Datenkorrektheit' für den Kontext bisher nicht definiert. Wenn ich dieses Wort hinschreibe, meine ich nicht, daß eine alle Ebenen umfassende garantierte Datenkorrektheit stets vorliegen wird. Sondern ich meine damit, daß mit allergrößter Wahrscheinlichkeit, Kommandos, die ich starte, ihre Arbeit ohne einen einzigen vorkommenden Datenfehler erledigen können.

Prinzipiell ist das so. Du übertreibst bei den Formulierungen allerdings ein wenig.

Und es kann durchaus sein, daß dieses ODECC Bits repariert, die bei DDR4 ohne jegliches ECC falsch weitergereicht worden wären.

Am 26.07.23 um 15:53 schrieb Michael Schwingen:

Setzt aber IIRC voraus, daß dein ECC nur still vor sich hinkorrigiert und nichts weiter unternimmt. Wenn bei korrigierbaren Fehlern gewarnt wird und bei nichtkorrigierbaren das System angehalten, was bei Linux Standardeinstellung sein sollte, wird man wegen der Streuschuß-Methodik von Rowhammer allenfalls das attackierte System anhalten können.

Hanno

Ach... und die meinen es fällt nicht auf wenn sich die Logs mit erkannten ECC-Fehlern füllen? Einige OS (unter anderem Solaris) merken sich auch wie oft ein ECC-Fehler aufgetreten ist und wenn dasselbe Wort mehrfach auffällt wird die Page aus dem Pool genommen.

Und falls du einen 2Bit-Fehler produzierst kommt es auf das OS an, manche schiessen nur das Programm ab, andere legen gleich eine System-Panic hin.

Gerrit

Es kommt auf die Definition von "vollkommene Datenkorrektheit" an. Bisher habe nur ich eine Definition für den Kontext abgegeben.

Ich bin ganz sicher, daß wenn ich ein Kommando laufen lasse, dieses seine Arbeit ohne einen einzigen vorkommenden Datenfehler erledigen kann, durch beide ECC-Systeme. Nur eine Garantie dafür habe ich nicht.

Soll man deshalb alle diese Test-Tools abschaffen?

Und das reicht mir. Ein Fehlervorkommnis noECC : ECC = 16000 : 0,015 sah ich einmal im Netz.

Du schwurbelst.

"Korrekt" kennt keine Abstufungen. Entweder, die Daten sind korrekt, oder sie sind es nicht. "mit allergrößter Wahrscheinlichkeit korrekt" ist eben nicht korrekt. Das mag gut genug sein, aber dann ist "korrekt" der falsche Begriff für das, was Du meinst.

cu Michael

"Korrekt" wird im allgemeinen (wenn nicht genauer spezifiziert wird, was dabei korrekt sein soll) für eine Angabe verwendet, die inhaltlich richtig ist und/oder Anforderungen an ihre Schreibweise genügt.

Ich könnte beispielsweise ein Originalbit und ein Kopiebit haben. Sind beide "0", so ist die Kopie offensichtlich eine Kopie des Originals. Ich könnte also definieren: "Ein Bit einer Kopie ist /korrekt/, wenn sein Zustand genauso ist wie der Zustand des Originals.".

Es könnte aber auch sein, daß beide ursprünglich "1" waren und durch einen unglücklichen Zufall sowohl das Original als auch die Kopie später auf "0" gekippt sind. Man würde dann die "0" auch als "korrekt" ansehen, weil der Zustand wie beim Original ist, obwohl beide verfälscht wurden.

Man könnte auch definieren, daß ein Bitzustand "korrekt" ist, wenn er sich seit dem letzten Schreibvorgang nicht verändert hat, aber dies kann man im allgemeinen nicht überprüfen.

Letztendlich wird die Entwicklung von Zuständen durch die Quantentheorie beschrieben. Dort gibt es zwei in diesem Zusammenhang relevante Aussagen:

Die letzten beiden Absätze wirken zunächst etwas esoterisch, aber sie werden relevant, sobald man sich mit Quantenrechnern beschäftigt!

Helmut Schellong schrieb:

Das ist schlicht falsch. "Vollkommene Datenkorrektheit" impliziert ohne jede weitere Definition eines Kontextes, dass die Daten sämtlich ohne jeden Fehler verarbeitet werden bzw. wurden. Es wirkt übrigens immer wieder etwas arg skurril, wenn du versuchst, dein fehlendes Wissen bzw., so wie hier, völliges Unwissen durch Bezug auf den stets "falschen Kontext" zu relativieren. Dir fehlt halt, wie alle hier wissen, eine fundierte Ausbildung im E-Technik-Bereich, aber das ist doch kein Grund, ständig zu versuchen, das durch Schwurbelei wegzureden. Niemand muss sich dafür schämen, dass er das Studium nicht geschafft hat - schließlich ist ja nicht jeder für seine Wunschausbildung geeignet

Da kannst du nicht sicher sein, wie dir jeder Lehrling im ersten Lehrjahr erklären kann

Du kannst niemals sicher sein, schon garnicht dadurch, dass du dich lediglich auf ECC-Verfahren verlässt. Schon das übliche ECC-Verfahren, welches, unter Verwendung zusätzlicher, redundanter Datenspeicher, wohl die Wahrscheinlichkeit des Auftretens unerkannter Fehler ab dem Speichercontroller der CPU bis hin zu den einzelnen RAM-Zellen verringert, kann natürlich Fehler nicht generell und vollständig ausschließen. Das On-Die-ECC von DDR5-RAM hilft insoweit keinen Deut weiter, weil es zwar generell die Wahrscheinlichkeit von Fehlern zu verringern geeignet ist, aber keinerlei Information über aufgetretene/korrigierte Fehler liefern kann.

Nein. Aber du müsstest halt verstehen lernen, wozu solche Tools dienen können - und wozu nicht.

Das hilft leider wenig. Es hilft im konkreten Fall nämlich überhaupt nicht weiter

MfG Rupert

Helmut Schellong schrieb:

Selbst wenn dem so sein sollte - was solls? Ob eine einmalige Aktion zur Datenkonversion nun 10 Minuten oder mehrere Stunden dauert, ist regelmäßig völlig egal. Als ich noch mit derlei Aktionen beschäftigt war, hießen die beteiligten Rechner Siemens MX2 (die Ausgangssysteme) und die Zielsysteme waren Siemens MX300, Systeme auf i486 Basis mit bis zu 50MHz Taktfrequenz und bis zu 64MB RAM, man nannte das damals "mittlere Datentechnik". Da dauerten Ex- und Import der Datenbank einer mittelmäßigen Behörde tatsächlich etliche Stunden, weshalb wir das oft am Wochenende machten

Jeder kauft mal zu teuer. Beim nächsten mal informierst du dich besser vorher

Ja, hast du. Aber wozu?

Wenn du meinst...

MfG Rupert

Am 26.07.2023 um 20:11 schrieb Michael Schwingen:

Ich definiere dann meine Definition noch ausführlicher: Ich lasse ein Kommando laufen. Das Kommando beendet seine Arbeit, ohne daß ein einziger Datenfehler vorkam. Derjenige Lauf geschah dann mit vollkommener Datenkorrektheit. Gemäß der Wahrscheinlichkeit mit 2 ECC-Systemen werden 350000 solche Kommando-Läufe ohne einen Datenfehler ablaufen. Bis zum Ende meines Lebens werde ich bei 1750 Läufen maximal 2-mal einen Datenfehler mit dem Kommando erleben. Dies ist allerdings der WorstCase, folglich äußerst unwahrscheinlich. Also - ich kann damit leben.

Am 26.07.2023 um 21:40 schrieb Rupert Haselbeck:

Ja, korrekt, das definiere ich selbst ja auch andauernd so.

Die zeitliche Ebene muß einbezogen werden, andernfalls wird es ungenau und mißverstanden.

Der Kontext muß stets genannt werden, sonst redet man aneinander vorbei.

Blödes und falsches Geschwurbel.

Das ist falsch. "Ich bin ganz sicher" ist eine persönliche Einschätzung, mit der man daneben liegen kann. Diese Einschätzung basiert auf mannigfaltigen bisherigen Beobachtungen.

Die Wahrscheinlichkeit, daß ich in meinem Leben einen negativ wirksamen Datenfehler mit meiner Workstation erleben werde, ist praktisch Null. Darauf kommt es an - es erhebt sich einfach über die Theorie.

Diese Tools zeigen alle vorhandenen Fehler mit extrem großer Wahrscheinlichkeit an. Das reicht mir.

Es hilft extrem stark dabei, daß man keinen negativ wirksamen Datenfehler erleben wird. Es ist eindeutig sehr hilfreich - sehr stark wirkend.

Unter 20 Datenfehlern wird wohl nur einer sein, der schädlich wirkt. Und dieser schädliche würde hochwahrscheinlich einen harmlosen Schaden verursachen. Ein neuer Aspekt für Dich?

Mein alter PC von 2006 ohne ECC hat ein so gutes RAM, daß es wohl höchstens 50 Datenfehler in diesem Zeitraum gab - unbemerkte, harmlose Fehler ohne bleibende Schäden.

Am 26.07.2023 um 22:00 schrieb Rupert Haselbeck:

Ja, eine einmalige solche Aktion ist mit Stunden an Zeitbedarf ziemlich egal. Allerdings hatte ich 6 Läufe. Ich habe nämlich die Suchmuster fortlaufend geändert/optimiert, aufgrund des Inhalts der Resultat-Datei. Bei 5 Minuten jeweiliger Laufzeit kein Problem.

Es kann auch sein, daß ich mal Newsgroups inhaltlich analysiere. Mit Regulären Ausdrücken der höchsten Kategorie. Die Datenmengen sind gewaltig. Und es sind immer wieder solche extrem aufwendigen Datenläufe notwendig.

Das habe ich, deshalb kaufte ich 22 TB nicht, sondern nur 18 TB.

Damit der Sinn meines Kaufes einer Workstation klar wird.

Rupert Haselbeck schrieb:

Ja, Papa.

Stefan Ram schrieb:

Man bekommt da recht schnell fundamentale Logikprobleme

Am 26.07.2023 um 23:32 schrieb Helmut Schellong:

Mir fällt auf, daß im Kontext überwiegend mit theoretischen Möglichkeiten kokettiert wird. Es ist beispielsweise theoretisch möglich, daß die Lottozahlen 1 2 3 4 5 6 gezogen werden, und bei der nächsten Ziehung die Lottozahlen 2 3 4 5 6 7. Beim Würfeln kann theoretisch auch hintereinander 1 2 3 4 5 6 6 6 6 6 6 vorkommen. (Das sind halt Spielereien mit der Theorie.)

In der realen Praxis ist dies jedoch noch nie vorgekommen. Vielleicht kommt das in 10366 Jahren mal vor - unbekannt. In der Realität liegt nämlich stets eine statistische Verteilung vor. Starke Häufungen kommen selten vor, je schwächer diese sind, desto häufiger.

Es kam in der Praxis vor, daß mehrere Ziehungen hintereinander niemand 6 Richtige hatte. Bei _einer_ Ziehung kamen immer wieder mal mehrere 6er-Treffer vor. Das Wort 'mehrere' kann jedoch für die Praxis nicht durch das Wort 'viele' ersetzt werden.

Wegen des faktischen Verhaltens in der Realität, sind Vorrichtungen wie ECC auch enorm wirksam.

Warum wurden bei Hashes sha256 bisher keine Kollisionen bekannt? Weil Kollisionen hier zwar theoretisch milliardenfach zwingend vorkommen müssen, dies jedoch in der Praxis bisher nicht taten. Die extrem geringe Anzahl bisheriger realer Hash-Prüfungen reicht von der Wahrscheinlichkeit her einfach nicht aus, um Kollisionen zu zeigen.

Thus spoke Rupert Haselbeck:

Das hängt allerdings davon ab, um wieviele und welche Festplatten es geht. Für die beiden WD140EFGX in meinem Heimserver (RAID1) habe ich im Dezember '21 auch gute 600 EUR bezahlt - zur damaligen Zeit ein fairer Kurs.

^^ Du hast da ein "ir" vergessen.

Tschüs,

Sebastian

Am 27.07.2023 um 00:24 schrieb Helmut Schellong:

Test-Arten:

-----------

Wer diese Tests mit 0 Fehlern durchläuft, hat mit extrem hoher Wahrscheinlichkeit ein vollkommen intaktes RAM.

Am 17.07.2023 um 17:22 schrieb Helmut Schellong:

An die CPU-Temperatur bei 33°C glaube ich mittlerweile nicht mehr. Ich meine damit, daß es sich nicht um die Chip-Temperatur der CPU handelt.

Wenn der Wärmewiderstand zwischen Chip und Gehäuse beispielsweise 0,1°C/W beträgt, würde die Temperatur des Chips bei 100W Leistungssteigerung innerhalb von z.B. 0,1 s um 10°C steigen, weil der Chip eine geringe Temperaturkapazität hat.

Da dieser Charakter nicht vorliegt und die CPU-Temperatur stets ziemlich gering ist, glaube ich nicht an eine Messung per on-die-Diode.