Workstation: erste Tests

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.

Axel Berger, 2023-07-25 22:30:

Es ging mir auch nicht um die Wahrscheinlichkeit, wie oft sowas vorkommt, sondern die falsche Annahme, dass Prüfsummen *garantieren* könnten, dass Daten fehlerfrei sein.

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

Nein, genau so ist es.

Du hast selbst geschrieben, Zitat:

"Wenn ich zwei große identische Testläufe mache und die Resultatdateien

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.

Korrekt.

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.

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:

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

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

Ja, und das ist ein Fehler. Aber MS und sauberes Design...

Gerrit

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

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

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.

Hanno Foest, 2023-07-28 00:02:

Ja, solche Fälle kenne ich auch - memtest86+ kann auch mal 24 Stunden fehlerfrei laufen und am Ende ist das System wegen Bitfehlern im RAM trotzdem instabil. Das fällt dann zwar nur alle paar Monate auf, aber in solchen Fällen ersetze ich in der Regel das RAM komplett, egal ob memtest86+ etwas findet oder nicht.

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

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

D.h. die Entwicklungen werden veröffentlicht?

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.

Eben.

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

Ich hatte schon so ein Problem. Beim Kopieren von großen Files konnte es einzelne Bitkipper geben (1 Bit defekt in 10 GB). Das Problem verschwand als ich die DIMMs in das andere Sockelpaar gesteckt habe. Das RAM war also OK, die Signale zwischen CPU und DIMMs hingegen an der Grenze.

Gerrit

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

Die Frage war, warum man serienmäßig sowas einbaut, wenn man doch auch 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.

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.

Kann man aber nur nutzen wenn das Mainboard auch mitspielt. Meines tut das.

Gerrit

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

Das ist aber nur Maskerade!

Die beiden Ordner heißen auf Systemebene anders:

C:\PROGRA~1 C:\PROGRA~2

Die echten Namen bekommt man mit "dir /X" angezeigt.

Gruß Andreas

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

Das ist nicht die "Systemebene", es sind 8.3-Namen. Bei neueren Windows-Versionen sind solche Namen entbehrlich und können mit "FSUTIL" abgestellt werden. Windows kann dann grundsätzlich weiterhin arbeiten. Da es aber trotzdem Probleme bereiten könnte, würde ich das nicht empfehlen, obwohl bestimmte Dateioperationen dann etwas schneller sind.

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

Gerrit

Am 28.07.23 um 01:19 schrieb Axel Berger:

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.

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.

Hanno

Gerrit Heitsch, 2023-07-28 09:06:

Was hat "Dateibenennung" mit "sauberem Design" zu tun? Programme sollten mit Leerzeichen in Dateinamen umgehen können. Auch unter Linux oder macOS ist das nicht verboten. Wenn man das nicht wollte, hätte man Leerzeichen als Teil des Dateinamens verbieten sollen - hat man aber nicht, auch nicht unter Linux oder macOS.

Andreas Fecht, 2023-07-28 10:33:

Nein, das sind die *erzeugten* Namen in 8+3-Schreibweise für Uralt-Software, die mit langen Dateinamen nicht umgehen kann.

Alternativ "dir /?"

Aus obiger Website, Zitat:

/x

Zeigt die kurzen Namen an, die für Nicht-8dot3-Dateinamen generiert werden. Die Anzeige entspricht der Anzeige mit /n, der kurze Name wird jedoch vor dem langen Namen eingefügt.

(Zitat Ende)

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

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.