Workstation: erste Tests...

[Michael Schwingen]

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

Ja, ARM hat mächtig aufgeholt und ist auch am Markt mächtig gut vertreten.
Zur Zeit des Alpha kannte ich ARM aber noch nicht.

Alpha war ab 1992, der EV5 kam 1995.

Ebenfalls 1995 hat DEC den StrongARM entwickelt (und ab 1996 ausgeliefert),
spätere Versionen (SA110) waren in den letzten Apple Newton (ab MP2000) und
haben dort für eine ordentliche Geschwindigkeitssteigerung gegenüber dem
Vorganger geführt.

Hier liegen noch 2 Empeg Car:

https://www.empeg.com/

Der StrongARM bootet ein Linux von der 2.5\"-Festplatte und beginnt 7
Sekunden nach dem Einschalten, Musik zu spielen (coldboot, kein Standby).

Das liegt jetzt mehr am durchdachten Systemdesign und weniger am StrongARM,
aber solche Bootzeiten bekommen viele moderne Systeme mit Flash nicht hin.

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

 

[Helmut Schellong]

Am 26.07.2023 um 13:00 schrieb 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.

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

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

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

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

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.

Ja.

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

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.

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.

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.

Dafür brauchte ich die Workstation nicht.

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

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

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.

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.

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

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 26.07.2023 um 14:30 schrieb 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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 26.07.2023 um 14:53 schrieb 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:

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

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.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hanno Foest]

Am 26.07.23 um 15:53 schrieb Michael Schwingen:

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/

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

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

 

[Gerrit Heitsch]

On 7/26/23 15:53, Michael Schwingen wrote:

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/

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

 

[Helmut Schellong]

Am 26.07.2023 um 15:45 schrieb 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.

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.

Ich habe bereits mit memtest86+ geprüft.

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

Soll man deshalb alle diese Test-Tools abschaffen?

Meistens ergibt sich aber doch Datenkorrektheit.

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

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Michael Schwingen]

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

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.

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
--
Some people have no respect of age unless it is bottled.

 

[Stefan Ram]

Michael Schwingen <news-1513678000@discworld.dascon.de> writes:

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

\"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:

1.) Solange keine Messung stattfindet, entwickelt sich der
Zustand eines isolierten Systems unitär. Das heißt, daß
Information nicht verloren gehen kann. Doch in der Praxis
kann Information so dissipiert sein, daß es unmöglich ist
sie wiederzugewinnen, außerdem kann man Systeme schlecht
perfekt isolieren und jede Messung vermeiden.

2.) Es gibt in der Quantentheorie auch ein sogenanntes \"No-cloning
Thoerem\", das besagt, daß man vom Zustand eines Systems keine
Kopie machen kann. Dies bereitet allerdings beim Kopieren von Bits
in der Praxis üblicher EDV-Geräte keine Probleme, weil man hier
nicht den vollständigen quantenmechanischen Zustand kopieren muß.

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

 

[Rupert Haselbeck]

Helmut Schellong schrieb:

Michael Schwingen:
Helmut Schellong 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.

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

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

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.

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

> Nur eine Garantie dafür habe ich nicht.

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.

Ich habe bereits mit memtest86+ geprüft.

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

Soll man deshalb alle diese Test-Tools abschaffen?

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

Meistens ergibt sich aber doch Datenkorrektheit.

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

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

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

MfG
Rupert

 

[Rupert Haselbeck]

Helmut Schellong schrieb:

Rupert Haselbeck:
Ein PC für 350 EUR würde wohl nicht ein paar Minuten, sondern eher
Stunden benötigen.

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

> (Meine Festplatten kosten bereits 900 EUR.)

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

Ich habe mehrfach dargestellt, daß die Workstation in der Regel
etwa 50-fach schneller ist, als meine alte Plattform mit E8600 3333 MHz.

Ja, hast du. Aber wozu?

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

Wenn du meinst...

MfG
Rupert

 

[Helmut Schellong]

Am 26.07.2023 um 20:11 schrieb Michael Schwingen:

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

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.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 26.07.2023 um 21:40 schrieb Rupert Haselbeck:

Helmut Schellong schrieb:
Michael Schwingen:
Helmut Schellong 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.

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

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.

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

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

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

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

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

Blödes und falsches Geschwurbel.

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.

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

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.

Nur eine Garantie dafür habe ich nicht.

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.

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.

Ich habe bereits mit memtest86+ geprüft.

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

Soll man deshalb alle diese Test-Tools abschaffen?

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

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

Meistens ergibt sich aber doch Datenkorrektheit.

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

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

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 26.07.2023 um 22:00 schrieb Rupert Haselbeck:

Helmut Schellong schrieb:
Rupert Haselbeck:
Ein PC für 350 EUR würde wohl nicht ein paar Minuten, sondern eher Stunden benötigen.

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

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.

(Meine Festplatten kosten bereits 900 EUR.)

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

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

Ich habe mehrfach dargestellt, daß die Workstation in der Regel
etwa 50-fach schneller ist, als meine alte Plattform mit E8600 3333 MHz.

Ja, hast du. Aber wozu?

Damit der Sinn meines Kaufes einer Workstation klar wird.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Rupert Haselbeck schrieb:

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

Ja, Papa.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Stefan Ram schrieb:

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

Man bekommt da recht schnell fundamentale Logikprobleme

https://de.wikipedia.org/wiki/Gettier-Problem#Elimination_falscher_Annahmen

Andererseits, irgendwie haben auch Kernspeicher funktioniert.
Dort kann man prinzipiell nur destruktiv auslesen.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 26.07.2023 um 23:32 schrieb Helmut Schellong:

Am 26.07.2023 um 20:11 schrieb Michael Schwingen:
On 2023-07-26, Helmut Schellong <var@schellong.biz> wrote:

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.

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.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 27.07.2023 um 00:24 schrieb Helmut Schellong:

Am 26.07.2023 um 21:40 schrieb Rupert Haselbeck:
Helmut Schellong schrieb:
Michael Schwingen:
Helmut Schellong wrote:
[...]
Ich habe bereits mit memtest86+ geprüft.

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

Soll man deshalb alle diese Test-Tools abschaffen?

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

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

Test-Arten:
-----------
00 Adressentest, fortschreitende Einsen
01 Adressentest, eigene Adresse
03 Bewegte Inversionen, Einsen & Nullen
04 Bewegte Inversionen, 8-bit-Muster
05 Bewegte Inversionen, Zufallsmuster
06 Blockbewegung, 64-byte-Blöcke
07 Bewegte Inversionen, 32-bit-Muster
08 Zufallszahlensequenz
09 Modulo 20, Einsen & Nullen
10 Test auf verblassende Bits, 2 Muster
13 Hammer-Test
14 DMA-Test

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 17.07.2023 um 17:22 schrieb Helmut Schellong:

Am 17.07.2023 um 16:31 schrieb Helmut Schellong:
[...]
CPU-Streßtest:

In Ruhe liegen etwa 90 W bei 800 MHz vor.
Bei Streß sind es 270..320 W bei 3700 MHz.
Die Lüfter haben dabei etwa 70% ihrer maximalen Drehzahl, vor Streß 45%.
CPU-Temperatur konstant bei 33 Grad (auch vor dem Streß).
Temperaturen maximal bei etwa 60% ihrer Alarmschwelle.
CPU-Core-Spannung  1 / 0,68 V  bei  Streß / Idle.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hanno Foest]

Am 27.07.23 um 20:16 schrieb Helmut Schellong:

[memtest86+]

Test-Arten:
-----------
00  Adressentest, fortschreitende Einsen
01  Adressentest, eigene Adresse
03  Bewegte Inversionen, Einsen & Nullen
04  Bewegte Inversionen, 8-bit-Muster
05  Bewegte Inversionen, Zufallsmuster
06  Blockbewegung, 64-byte-Blöcke
07  Bewegte Inversionen, 32-bit-Muster
08  Zufallszahlensequenz
09  Modulo 20, Einsen & Nullen
10  Test auf verblassende Bits, 2 Muster
13  Hammer-Test
14  DMA-Test

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

Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen, bis
sich die ersten Fehler zeigten. Mit etwas mehr Pech hätten es auch 3
Tage (oder mehr) sein können.

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