Workstation: erste Tests...

[Arno Welzel]

Axel Berger, 2023-07-28 11:01:

Arno Welzel wrote:
MD5 gilt mittlerweile nicht mehr als sicher,

Es macht aber schon einen Unterschied, ob ich mich nur gegen
Kopierfehler schützen will oder auch gegen böswillige Veränderung.

Ja, für letzteres genügt MD5, um anhand des Hash zu prüfen, ob das
Original fehlerfrei kopiert wurde. Dass ein Kopierfehler *zufällig* zum
gleichen MD5-Hash führt, wie der originale Dateiinhalt, ist so
unwahrscheinlich, dass man dieses Risiko vernachlässigen kann.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Hanno Foest, 2023-07-28 13:52:

Am 28.07.23 um 01:19 schrieb Axel Berger:

Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen,

Ist Memtest überhaupt noch sinnvoll? Ich kenne es aus der Zeit, als
zweistellig MB RAM viel war. Schon mit einem halben Gigabyte schafft man
es kaum noch, den ganzen Zyklus auch nur einmal durchlaufen zu lassen.

Kann ich so nicht bestätigen. Das mit den 18 Stunden ist ne Weile her,
es waren so 4GB, und memtest hat schon ein paar Runden geschafft.

Na ja - heutige PCs haben auch mal 32, 64 oder 128 GB RAM. Das wird dann
schon etwas zeitaufwendiger.

Die andere Frage ist, was du messen willst. Wenn memtest Fehler wirft,
weiß du definitiv, daß das RAM (in dieser Konfiguration) kaputt ist. Du
kannst aber nicht verifizieren, daß es heil ist. Das ist letztendlich
das alte Verifikationsproblem aus den Erkenntniswissenschaften: Das
Ergebnis *könnte* sich morgen spontan geändert haben.

Für mich war obiges Erlebnis Anlaß, mich nach günstigen ECC Lösungen
umzusehen, und sie nach Möglichkeit (für Laptops kann man das knicken)
einzusetzen.

DDR4 ECC unbuffered läuft auch auf vielen AMD-Boards mit Ryzen 7. Sowas
gibt\'s auch halbwegs günstig - z.B. 32 GB PC4-3200, ECC unbuffered von
Kingston ca. 80 EUR pro Modul.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-26 16:24:

Am 26.07.2023 um 13:00 schrieb Rupert Haselbeck:
[...]
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.)

Und meine SSDs weit weniger als 900 EUR, trotzdem reicht\'s für fast 8 TB
Speicherkapazität mit 0,9 - 3 GB/s Durchsatz lesend und schreibend und
entsprechend hohen IOPS-Zahlen. 128 GB ECC-RAM gibt\'s für die von mir
benutzte Plattform auch für unter 400 EUR (aktuell ca. 320 EUR). Und das
Mainboard hat weniger als 200 EUR gekostet.

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

Ja, das ist ja auch keine Kunst. So ziemlich *jede* aktuelle Hardware
ist vielfach schneller als das.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-27 00:49:

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.

100 GB Daten durchsuchen würde mein \"Mainstream-PC\" vermutlich auch in
weniger als 5 Minuten durchlaufen.

Es kann auch sein, daß ich mal Newsgroups inhaltlich analysiere.
Mit Regulären Ausdrücken der höchsten Kategorie.

Wo sind die Kategorien von regulären Ausdrücken definiert?

Die Datenmengen sind gewaltig.
Und es sind immer wieder solche extrem aufwendigen Datenläufe notwendig.

Warum?

[...]

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.

Nein, das ist das Ergebnis des Kaufs. Der Sinn dahinter, warum sie so
schnell sein soll, ist nicht klar.

In meinem (Arbeits-)Alltag komme ich mit Laptops der Sorte Dell Latitude
5430 gut aus und daneben gibt es noch einen PC mit AMD Ryzen 7, viel RAM
und viele SSDs, auf dem in der Regel 2-3 VMs fast immer laufen. Da merke
ich auch nichts davon, dass irgendwas langsam wäre. Eine 4K-Video mit 2
Stunden Laufzeit umkodieren dauert je nach Codec und Einstellungen mit
Beteiligung der GPU ca. 10-15 Minuten - das reicht mir.

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

Am 28.07.2023 um 00:02 schrieb 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.

Sehr lustig?
Ich schrieb nicht, daß da nur 1 Pass eingestellt werden soll.

Voreingestellt sind 4 Passes, was erhöht werden kann.
Es ist doch ganz klar, warum da 4 voreingestellt ist, und
warum es überhaupt einstellbare Passes gibt!


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Gerrit Heitsch schrieb:

On 7/27/23 14:25, Wolfgang Allinger wrote:

On 27 Jul 23 at group /de/sci/electronics in article u9tior$1s3t7$1@dont-email.me
rolfnospambombach@invalid.invalid>  (Rolf Bombach)  wrote:

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

und muss sie sofort wieder rückspeichern. Klappte hervorragend.

Das gleiche gilt für DRAMs, Auslesen ist destruktiv.  Das Zurückschreiben ist allerdings im RAM integriert und passiert automatisch am Ende des Zugriffs.

THX, wusste ich nicht.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 28.07.2023 um 01:19 schrieb Axel Berger:

Hanno Foest wrote:
Sehr lustig. Ich hab memtest86+ 18 Stunden laufen lassen müssen,

Ist Memtest überhaupt noch sinnvoll? Ich kenne es aus der Zeit, als
zweistellig MB RAM viel war. Schon mit einem halben Gigabyte schafft man
es kaum noch, den ganzen Zyklus auch nur einmal durchlaufen zu lassen.
Ja, natürlich habe ich es über Nacht laufen lassen und dann auch mal
einen ganzen Tag und eine ganze Nacht, aber so richtig weit im Programm
kam es nicht.

Es gibt zwei \'memtest\'.
Das \'memtest86\' von Passmark finde ich besser.
In einer knappen Stunde ist 1 Pass erledigt.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Arno Welzel schrieb:

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

Nunja, der Kompressor kennt ja den Inhalt nicht und geht
nach Schema F vor. Würde er den Inhalt verstehen und tatsächlich
den Code komprimieren, nicht auszudenken, was bei heutiger
Bloatware passieren würde. Wahrscheinlich Kompression
auf 0 Bytes und der Code passt in den Filenamen.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Volker Bartheld schrieb:

On Thu, 20 Jul 2023 22:38:22 +0200, Rolf Bombach wrote:
Helmut Schellong schrieb:
WS = Xeon 3435X, 16 Kerne, 32 CPUs, Basis 3100 MHz, 128 GB
PC = 2006 E8600,  2 Kerne,  2 CPUs, 3333 MHz, 4 GB
Single-Thread:   683/272 =  2,5
Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt
es keine wirklich grossen Sprünge mehr.

Weswegen Cryptominer, Videocutter, VFX-Artisten, CAD-Ingenieure,
Elementarteilchenphysiker und KI-Forscher ja auch auf 10 Jahre altem
Equipment beharren.

[sup] Oh, und Softwareentwickler. Die hatte ich vergessen.

Des Lesens mächtig hast du sicher erkannt, dass es hier um
die Single-Fred-Leistung geht. Ausserdem mag es dich
überraschen, dass es sehr viele, auch prozentual, User
gibt, die nicht Cryptos schürfen oder CERN-Daten auswerten.
Und eher noch nach der N(atürlichen)I suchen *duck*.
Und nicht jeder \"publiziert\" auf youtube.

Du redest von Zeuch, dass sich parallelisieren lässt oder das
schon von sich aus tut.

Tut eigentlich LTspice auch, allerdings ist bei nicht allzu
grossen Schaltungen der Geschwindigkeitsgewinn nur
etwa -0.2% bis +1% (95% Konfidenz) pro zugeschalteten Kern,
bei nur schwach von 0 verschiedenem Korrelationskoeffizienten.

Also sind wir wieder bei single thread.
Und ja, Serverprozessoren mit 256 Kernen oder so was gibt es.
Ideal für Leute, welche beim Mining von \'in 100 Jahren nicht
fertig\' auf \'in vier Jahren nicht fertig\' beschleunigen wollen.
(Falls sie überhaupt so doof sind, das auf einem PC-Prozessor
machen zu wollen).

--
mfg Rolf Bombach

 

[Michael Schwingen]

On 2023-07-27, Axel Berger <Spam@Berger-Odenthal.De> wrote:

Ist Memtest überhaupt noch sinnvoll? Ich kenne es aus der Zeit, als
zweistellig MB RAM viel war. Schon mit einem halben Gigabyte schafft man
es kaum noch, den ganzen Zyklus auch nur einmal durchlaufen zu lassen.

Kann ich nicht bestätigen. i7-2600 und 32GB RAM hat über Nacht mehr als einen
Durchlauf geschafft, also nutzbar.

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

 

[Helmut Schellong]

Am 28.07.2023 um 08:49 schrieb Arno Welzel:

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

Am 25.07.2023 um 20:38 schrieb Arno Welzel:
[...]
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.

Das ist eine problematische Formulierung.

Nein, genau so ist es.

Ich glaube nicht daran. Siehe unten.

Du hast selbst geschrieben, Zitat:

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

Man muß natürlich die beiden Tests in möglichst unterschiedlichen
RAM-Situationen durchführen.

Und damit hast Du ja vom Prinzip her genau das getan - zwei identische
Testläufe und anschließend die Prüfung, ob beide Ergebnisse gleich sind.

Diese Testläufe sind ein gänzlich anderer Algorithmus als eine Hash-Generierung.
Einerseits klarer als ein Hash, andererseits vielleicht weniger sicher.

Sicher ist, daß bei 1 Bit weniger mit allerhöchster Wahrscheinlichkeit ein
wirklich vollkommen anderer Hash entsteht.

Korrekt.

Eine Kollision liegt vor, wenn zwei (deutlich) unterschiedliche Dateien
den gleichen Hash generieren.

Und das ist zwangsläufig möglich, wenn der Hash kürzer ist, als die
Ausgangsdaten, aus denen er erzeugt wurde. Bei als \"sicher\" geltenden
Hashes ist nur der Aufwand zur Auffindung zweier Bitfolgen, die den
selben Hash ergeben, extrem hoch.

Ich habe da meine Zweifel, weil ich Hash-Algorithmen selbst implementierte.
Diese verrechnen ihre Eingabe mit einer Art Fleischwolf-Maschine, die qualitativ
dicht an echten Zufall herankommt.
Die Eingabe wird also komplett mit einem Zufallsgenerator vermischt.

Ich meine daher, es kommt nur auf die Gegenüberstellung an, wie viele
Zahlen der Hash bilden kann, und wie viele verschiedene Dateien es geben kann.
Kollisionen sind vorprogrammiert; die Hash-Werte müssen daher besonders gut
statistisch verteilt sein.

MD5 gilt mittlerweile nicht mehr als sicher, weil dort Kollisionen
bekannt sind und seit 2004 ein Verfahren, mit dem man diese auch in
relativ kurzer Zeit finden kann: <http://eprint.iacr.org/2004/199.pdf

Das ist mir bekannt, lange Zeit, bevor ich mehrere Hash-Algorithmen selbst implementierte.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

Helmut Schellong, 2023-07-26 16:37:

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.

Wer ist \"der OS-Hersteller\"? Welches OS? Bei Windows gibt es Dateinamen
mit Leerzeichen für sehr zentrale Verzeichnisse:

\"C:\\Program Files\"
\"C:\\Program Files (x86)\"

Kenne ich.
Aber ich meine SCO (Santa Cruz Operation), FreeBSD, Linux, Solaris.
Windows benutze ich überwiegend für Programme, die ich woanders nicht starten kann.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 09:13 schrieb Arno Welzel:

Helmut Schellong, 2023-07-27 00:24:

Am 26.07.2023 um 21:40 schrieb Rupert Haselbeck:
Helmut Schellong schrieb:
[...]
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.

Nein, Daten sind entweder korrekt oder nicht. \"Zeit\" ist in Bezug auf
*Daten* irrelevant.

Die \"zeitliche Ebene\" kann man nur auf die *Verarbeitung* der Daten
anwenden und z.B. beobachten, dass ein Verarbeitungsprozess, der 10
Minuten dauert, korrekte Daten liefert, während bei einer Dauer von 100
Stunden die Wahrscheinlichkeit für fehlerhafte Daten höher ist, wenn man
Bitfehler nicht durch geeignete Prüfverfahren erkennen kann.

Ich verstehe Deine Denkweise nicht.
Ich definiere einen großen Testlauf, der 110 GB Daten aufwendig filtert.
Und der braucht seine Zeit - also sind wir bei Zeit.
Während dieser Zeit können RAM-Fehler die Daten verfälschen.
Wenn dieser riesige Testlauf am nächsten Tag erneut gestartet wird, andere
RAM-Adressen verwendend, und exakt die gleichen Resultate (8 MB) generiert, gab es
keine RAM-Fehler in beiden Läufen - als Praxis-Beweis.

Ein besserer Beweis wäre die mehrfache Hash-Generierung von einer 50 GB großen Datei.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 09:23 schrieb Arno Welzel:

Helmut Schellong, 2023-07-25 21:29:

Am 25.07.2023 um 20:21 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.
Dasjenige ECC+Registered ist das zusätzliche äußere ECC.

AMD Ryzen 5 arbeitet mit DDR4 und unterstützt das \"zusätzliche äußere ECC\".

[...]
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\"?

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.

D.h. die Entwicklungen werden veröffentlicht?

Ja, teilweise. Siehe meine Webseite.

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.

Wenn es Dir Spaß macht, kannst Du gerne auch ein ganzes Rechenzentrum
kaufen. Nur die Begründung, dass Du sowas aus brauchst, weil Du als
Ingenieur arbeitest, finde ich etwas eigenwillig.

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

Eben.

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.

Und das Ergebnis der Analyse dieser Dateien wird dann irgendwann
veröffentlicht oder war eine Auftragsarbeit?

Nein, muß sie das, damit ich die Notwendigkeit einer Workstation belegen kann?
Das heißt, die Resultat-Datei habe ich hier veröffentlicht.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 15:48 schrieb Arno Welzel:

Helmut Schellong, 2023-07-27 00:49:

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.

100 GB Daten durchsuchen würde mein \"Mainstream-PC\" vermutlich auch in
weniger als 5 Minuten durchlaufen.

Wirklich? Messung!
Ich hatte gemessen.

Es kann auch sein, daß ich mal Newsgroups inhaltlich analysiere.
Mit Regulären Ausdrücken der höchsten Kategorie.

Wo sind die Kategorien von regulären Ausdrücken definiert?

Beispielsweise in den Manual-Seiten meiner bish-Shell.

Die Datenmengen sind gewaltig.
Und es sind immer wieder solche extrem aufwendigen Datenläufe notwendig.

Warum?

Beantworte ich nicht.

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

Nein, das ist das Ergebnis des Kaufs. Der Sinn dahinter, warum sie so
schnell sein soll, ist nicht klar.

Ist mir egal; beantworte ich halt nicht.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 15:43 schrieb Arno Welzel:

Helmut Schellong, 2023-07-26 16:24:

Am 26.07.2023 um 13:00 schrieb Rupert Haselbeck:
[...]
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.)

Und meine SSDs weit weniger als 900 EUR, trotzdem reicht\'s für fast 8 TB
Speicherkapazität mit 0,9 - 3 GB/s Durchsatz lesend und schreibend und
entsprechend hohen IOPS-Zahlen. 128 GB ECC-RAM gibt\'s für die von mir
benutzte Plattform auch für unter 400 EUR (aktuell ca. 320 EUR). Und das
Mainboard hat weniger als 200 EUR gekostet.

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

Ja, das ist ja auch keine Kunst. So ziemlich *jede* aktuelle Hardware
ist vielfach schneller als das.

Um wieviel schneller? Messung!
Ich hatte eine Messung gemacht.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 09:26 schrieb Arno Welzel:

Helmut Schellong, 2023-07-26 15:49:

Am 26.07.2023 um 12:16 schrieb Rolf Bombach:
Helmut Schellong schrieb:
[...]
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.

Die Frage war, warum man serienmäßig sowas einbaut, wenn man doch auch

Nein, das war nicht die Frage.
Die Frage war, _was_ dieses dann eigentlich genau tut.
Und die habe ich beantwortet.

RAM ohne ECC billiger anbieten könnte. Die Annahme ist, dass DDR5 ohne
ECC zu viele Fehler produzieren würde, weil es da kaum noch möglich ist,
stabilen Betrieb ohne Korrekturmaßnahmen sicherzustellen.

Ja, wurde hier kürzlich umfangreich durchgekaut.
DDR5 arbeitet zu hochfrequent.

Das ist ähnlich wie bei Festplatten mit extrem hohen Schreibdichten, wo
ein erheblicher Aufwand nötig ist, weil das, was der Lesekopf als Signal
liefert, schon lange nicht mehr direkt als Bits verarbeitbar ist.

Ja, die Spuren werden schon ineinander positioniert.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rupert Haselbeck]

Helmut Schellong schrieb:

Arno Welzel:
Helmut Schellong:
Arno Welzel:
[...]
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.

Das ist eine problematische Formulierung.

Nein, genau so ist es.

Ich glaube nicht daran. Siehe unten.

Du hast selbst geschrieben, Zitat:

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

Man muß natürlich die beiden Tests in möglichst unterschiedlichen
RAM-Situationen durchführen.

Hättest du tatsächlich eine ingenieurmäßige Ausbildung erfolgreich
absolviert oder auf andere Weise solche Kenntnisse erworben, dann
_wüsstest_ du, dass diese Aussage einfach nur Blödsinn ist.
Nur weil man zweimal dasselbe Ergebnis sieht, heißt das in keinem Fall,
dass die Daten bzw. deren Verarbeitung korrekt sein _müssten_. Lediglich
die statistisch herzuleitende Wahrscheinlichkeit, dass Daten bzw.
Algorithmus korrekt sein könnten, steigt. Ein Beweis ist etwas deutlich
anderes

Eine Kollision liegt vor, wenn zwei (deutlich) unterschiedliche Dateien
den gleichen Hash generieren.

Es ist hier egal, ob der Unterschied nur in einem einzigen Bit oder
vielen vielen Bits besteht

Und das ist zwangsläufig möglich, wenn der Hash kürzer ist, als die
Ausgangsdaten, aus denen er erzeugt wurde. Bei als \"sicher\" geltenden
Hashes ist nur der Aufwand zur Auffindung zweier Bitfolgen, die den
selben Hash ergeben, extrem hoch.

Ich habe da meine Zweifel, weil ich Hash-Algorithmen selbst implementierte.

O Gott! Ja, dann ist schon klar, woher deine Fehlvorstellungen mal
wieder kommen. Selbst gebastelte und damit unbrauchbare Algorithmen
erzeugen natürlich unbrauchbare Ergebnisse.
Wer hat deine Hash-Algorithmen denn hinsichtlich ihrer Qualität geprüft?

Diese verrechnen ihre Eingabe mit einer Art Fleischwolf-Maschine, die
qualitativ dicht an echten Zufall herankommt.
Die Eingabe wird also komplett mit einem Zufallsgenerator vermischt.

Aha...

Ich meine daher, es kommt nur auf die Gegenüberstellung an, wie viele
Zahlen der Hash bilden kann, und wie viele verschiedene Dateien es geben
kann.
Kollisionen sind vorprogrammiert; die Hash-Werte müssen daher besonders gut
statistisch verteilt sein.

Nicht wirklich. Einfach ausgedrückt ist der Clou bei derlei Dingen doch
nur, einen Algorithmus zu finden, welcher es möglichst schwierig macht,
eine Datei zu finden, welche denselben Hash-Wert wie die Originaldatei
ergibt. Und es muss natürlich auch unmöglich sein, aus dem Hash-Wert auf
die Eingabedaten Rückschlüsse zu erhalten.
Diese, und weitere, Voraussetzungen sind durch einzelne Menschen kaum
(besser: nicht) erreichbar, schon garnicht durch Amateure.

MfG
Rupert

 

[Rolf Bombach]

Arno Welzel schrieb:

Die 64-Bit-CPU in meinem Smartphone hat 8 Kerne mit verschiedenen
Taktfrequenzen:

2x ARM Cortex-A76 mit 2,25 GHz
4x ARM Cortex-A55 mit 1,8 GHz
2x ARM Cortex-X1 mit 2,8 GHz

Der Akku von dem Gerät hat nominell eine Kapazität von 16,97 Wh. Das
hält problemlos für 20-30 Stunden und selbst unter Last mehrere Stunden,
was ein Indikator ist, dass die CPUs selbst bei stärkerer Last mit weit
unter 16 Watt auskommen. Eine besondere Kühlung braucht das Gerät auch
nicht, es wird gerade mal handwarm, wenn es stärker ausgelastet wird.

Nominell hat die CPU eine TDP von gerade mal 5,6 Watt.

Die Story mit dem ersten ARM1 kennst du sicher....

Und ca. 2015 kam ja ein Apple-Rechner raus, der doppelt so
viel Rechenkraft hat wie die Cray 2.

--
mfg Rolf Bombach

 

[Rupert Haselbeck]

Helmut Schellong schrieb:

Arno Welzel:
Helmut Schellong:
Rupert Haselbeck:
Helmut Schellong schrieb:
[...]
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.

Nein, Daten sind entweder korrekt oder nicht. \"Zeit\" ist in Bezug auf
*Daten* irrelevant.

Die \"zeitliche Ebene\" kann man nur auf die *Verarbeitung* der Daten
anwenden und z.B. beobachten, dass ein Verarbeitungsprozess, der 10
Minuten dauert, korrekte Daten liefert, während bei einer Dauer von 100
Stunden die Wahrscheinlichkeit für fehlerhafte Daten höher ist, wenn man
Bitfehler nicht durch geeignete Prüfverfahren erkennen kann.

Ich verstehe Deine Denkweise nicht.

Das ist wohl zuvörderst deiner zwangsläufig laienhaften Herangehensweise
an wissenschaftliche Fragestellungen geschuldet

Ich definiere einen großen Testlauf, der 110 GB Daten aufwendig filtert.
Und der braucht seine Zeit - also sind wir bei Zeit.
Während dieser Zeit können RAM-Fehler die Daten verfälschen.
Wenn dieser riesige Testlauf am nächsten Tag erneut gestartet wird, andere
RAM-Adressen verwendend, und exakt die gleichen Resultate (8 MB)
generiert, gab es
keine RAM-Fehler in beiden Läufen - als Praxis-Beweis.

Das ist kein Beweis. Ein Beweis nach wissenschaftlichem, nach
ingenieurmäßigem Ansatz ist nicht das zufällige Ergebnis amateurhafter
Überlegungen. Dazu bedarf es eines wohldefinierten, beliebig
wiederholbaren und jederzeit auch für Dritte nachvollziehbaren Vorgehens.

Ein besserer Beweis wäre die mehrfache Hash-Generierung von einer 50 GB
großen Datei.

Ein Beweis ist genug. Es gibt keinen \"besseren\" Beweis

MfG
Rupert