Workstation: erste Tests...

[Arno Welzel]

Helmut Schellong, 2023-07-28 22:13:

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!

Wenn Du mit die Softare bereitstellst, messe ich gerne nach.

[...]

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

Warum?

Beantworte ich nicht.

Dann brauchst Du das ganze Thema hier nicht erwähnen. Oder ging es am
Ende nur um Schwanzvergleich?


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-28 22:07:

Am 28.07.2023 um 15:43 schrieb Arno Welzel:
[...]
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!

Irrelevant. Ich sagte nur \"vielfach schneller\".

Und zu \"Messung\": was genau soll gemessen werden? Worauf bezieht sich
dein \"50-fach schneller\"?

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

Am 19.08.2023 um 09:50 schrieb Arno Welzel:

Helmut Schellong, 2023-07-28 21:10:

Am 28.07.2023 um 08:49 schrieb Arno Welzel:
[...]
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.

Das ändert nichts daran, dass ein Hash, der *weniger* Bits hat, als die
zu prüfenden Datei, zwangsläufig nicht *jede* mögliche Quelldatei
*eindeutig* abbilden kann.

Deine nachfolgende Aussage ist aber falsch, angesichts des konkreten Algorithmus\'.

\"Und das ist zwangsläufig möglich, wenn der Hash kürzer ist, als die
Ausgangsdaten, aus denen er erzeugt wurde.\"

Ein Hash kann niemals eine Datei eindeutig abbilden!
Denn die Anzahl möglicher Dateien geht gegen unendlich.

Auch eine Datei, die nur 8 Bits enthält, kann Kollisionen verursachen.
Denn der konkrete hash-Algorithmus ist dafür schlicht blind.

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.

Das ist simpel: 2^n ist die theoretisch maximale Anzahl von Hash-Werten
für eine Länge von n Bits. Sobald eine Datei aber mehr als n Bits hat,
gibt es automatisch mehr verschiedene Dateien als Hashes.

Warum also zweifelst Du an der Aussage, dass bei einem Hash, der kürzer
ist, als die zu prüfende Datei, theoretisch bei zwei verschiedene
Dateien der selbe Hash entstehen kann?

Auch eine Datei, die nur 8 Bits enthält, kann Kollisionen verursachen.
Denn der konkrete hash-Algorithmus ist dafür schlicht blind.
Auch eine Datei mit 0 Bits erhält ihren Hash - stets ein und denselben.

Einer Datei mit 1 Bit sind genau zwei Hashes zugeordnet.
Mit jedem dieser beiden Hashes kann es eine Kollision geben, mit einer Datei, die
beispielsweise 236658543 Bits enthält.

Ich sprach von selbst implementierten hash-Algorithmen (Fleischwolf).
Ich hatte sogar den zugehörigen Code gepostet.

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.

Ist \"Hash-Algorithmen implementieren\" eine besondere Leistung oder wieso
erwähnst Du das hier merfach?

Ja, das ist eine besondere Leistung!
Jemand, der bisher nicht selbst implementierte, kann bei vielen verbundenen Themen nicht mitreden.
Es kommt oft Falsches dabei heraus.
Ich erkenne an dem implementierten Code, wie der Algorithmus sich verhält.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 09:53 schrieb Arno Welzel:

Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.
Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 12:10 schrieb Arno Welzel:

Helmut Schellong, 2023-07-29 13:07:

Am 29.07.2023 um 12:07 schrieb Thomas Prufer:
On Fri, 28 Jul 2023 00:02:55 +0200, Hanno Foest <hurga-news2@tigress.com> wrote:

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.

Hatte ich auch mal: Systemabstürze nach längerem Arbeiten.

Und memtest fand dann Fehler wenn memtest länger arbeitete... ich vermute
\"thermisch\", also \"irgendwas wird warm\".

Dauerte aber auch >>12h.

Das kann dann eigentlich nichts mehr mit der Temperatur zu tun haben.
Höchstens, daß durch Temperatur >>12h etwas stärker defekt wird.

Ich sehe Zeitkonstanten bei Temperatur von maximal 5 Minuten für CPU.
Je größer der Luftdurchsatz, desto kleinere Zeitkonstanten.

Verwechselst Du da nicht etwas? Je größer der Luftdurchsatz, desto
*länger* dauert es, bis die maximal mögliche Temperatur erreicht ist.

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 12:12 schrieb Arno Welzel:

Helmut Schellong, 2023-07-28 21:40:

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.

Das ist aber völlig irrelevant in Bezug auf \"Daten sind korrekt\".

Während dieser Zeit können RAM-Fehler die Daten verfälschen.

Genau das sagte ich doch! Lies doch einfach was ich schrieb zu 10
Minuten und 100 Stunden im Vergleich.

Du widersprichst Dir ständig selbst.

Es gab doch eine ausgedehnte Diskussion über Zeit und Fehler hier.
Da sagte jemand, er mußte mehr als 12 Stunden warten, bis ein Fehler auftrat.
Dieser Jemand sagte weiterhin, mehrere Tage Wartezeit wären auch möglich gewesen.

Folglich spielt Zeit im Zusammenhang mit Fehlern eine entscheidende Rolle.

Warum habe ich meinen Testfall so langzeitig ausgelegt?
Weil man das im professionellen Bereich so macht!
Bei meinem letzten Arbeitgeber wurden die Gleichrichter auch mehrere Stunden lang
unter Vollast gestreßt.
Auch, wenn bei 10 solchen Tests sich kein Fehler zeigt, wird diese Streßdauer
nicht gekürzt.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 12:16 schrieb Arno Welzel:

Helmut Schellong, 2023-07-28 22:13:

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!

Wenn Du mit die Softare bereitstellst, messe ich gerne nach.

Die hatte ich vor Monaten bereits hier veröffentlicht, per Cloud-Link.
Du müßtest jedoch auch die 110 GB original Daten haben...

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

Warum?

Beantworte ich nicht.

Dann brauchst Du das ganze Thema hier nicht erwähnen. Oder ging es am
Ende nur um Schwanzvergleich?

Ich mußte die Frage nicht beantworten, um deutlich zu machen, zu welchen
nützlichen Zwecken solche Datenläufe dienen können.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 12:20 schrieb Arno Welzel:

Helmut Schellong, 2023-07-28 22:07:

Am 28.07.2023 um 15:43 schrieb Arno Welzel:
[...]
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!

Irrelevant. Ich sagte nur \"vielfach schneller\".

Und zu \"Messung\": was genau soll gemessen werden? Worauf bezieht sich
dein \"50-fach schneller\"?

Das hatte ich hier mehrfach umfassend gepostet.
Es ist nun halt vorbei - ich poste das nicht nochmals.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 16:21:

Am 19.08.2023 um 09:53 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.

Die Vorgabe des NIST ist, mehrfach verschachtelte Makros zu benutzen?
Das glaube ich nicht.

Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.

Ich rede nicht von Komponenten, sondern das in Form \"mehrfach
verschachtelter Makros\" zu tun.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 16:06:

Am 19.08.2023 um 09:50 schrieb Arno Welzel:
Helmut Schellong, 2023-07-28 21:10:

Am 28.07.2023 um 08:49 schrieb Arno Welzel:
[...]
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.

Das ändert nichts daran, dass ein Hash, der *weniger* Bits hat, als die
zu prüfenden Datei, zwangsläufig nicht *jede* mögliche Quelldatei
*eindeutig* abbilden kann.

Deine nachfolgende Aussage ist aber falsch, angesichts des konkreten Algorithmus\'.

\"Und das ist zwangsläufig möglich, wenn der Hash kürzer ist, als die
Ausgangsdaten, aus denen er erzeugt wurde.\"

Ein Hash kann niemals eine Datei eindeutig abbilden!
Denn die Anzahl möglicher Dateien geht gegen unendlich.

Ja, das sagte ich ja.

Wenn Du Probleme hast, meinen Aussagen zu folgen, dann spare Dir einfach
weitere Kommentare dazu.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 16:41:

Am 19.08.2023 um 12:10 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 13:07:

Am 29.07.2023 um 12:07 schrieb Thomas Prufer:
On Fri, 28 Jul 2023 00:02:55 +0200, Hanno Foest <hurga-news2@tigress.com> wrote:

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.

Hatte ich auch mal: Systemabstürze nach längerem Arbeiten.

Und memtest fand dann Fehler wenn memtest länger arbeitete... ich vermute
\"thermisch\", also \"irgendwas wird warm\".

Dauerte aber auch >>12h.

Das kann dann eigentlich nichts mehr mit der Temperatur zu tun haben.
Höchstens, daß durch Temperatur >>12h etwas stärker defekt wird.

Ich sehe Zeitkonstanten bei Temperatur von maximal 5 Minuten für CPU.
Je größer der Luftdurchsatz, desto kleinere Zeitkonstanten.

Verwechselst Du da nicht etwas? Je größer der Luftdurchsatz, desto
*länger* dauert es, bis die maximal mögliche Temperatur erreicht ist.

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?

Bei höherem Luftdurchsatz dauert es länger, weil mehr Wärme pro
Zeiteinheit abgeführt wird. Aber Du kannst mir das Gegenteil gerne
vorrechnen.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 17:10:

Am 19.08.2023 um 12:12 schrieb Arno Welzel:
Helmut Schellong, 2023-07-28 21:40:

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.

Das ist aber völlig irrelevant in Bezug auf \"Daten sind korrekt\".

Während dieser Zeit können RAM-Fehler die Daten verfälschen.

Genau das sagte ich doch! Lies doch einfach was ich schrieb zu 10
Minuten und 100 Stunden im Vergleich.

Du widersprichst Dir ständig selbst.

Nein, Du verstehst es nur wieder nicht.

[...]
> Folglich spielt Zeit im Zusammenhang mit Fehlern eine entscheidende Rolle.

Nein, im *Ablauf* spielt die Zeit eine Rolle!

Im *Ergebnis* ist es egal, ob die Daten nach 10 Minuten oder 100 Stunden
korrekt oder falsch sind. Entweder sind sie korrekt oder eben nicht. Die
generelle Aussage, ob Daten korrekt sind, hängt exakt *gar* *nicht*
davon ab, ob dies durch einen Prozess mit 10 Minuten Laufzeit oder 100
Stunden Laufzeit zustand gekommen sind.



--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 17:21:

Am 19.08.2023 um 12:16 schrieb Arno Welzel:
[...]
Wenn Du mit die Softare bereitstellst, messe ich gerne nach.

Die hatte ich vor Monaten bereits hier veröffentlicht, per Cloud-Link.
Du müßtest jedoch auch die 110 GB original Daten haben...

Also nicht - auch gut. Dann spare Dir Forderungen nach irgendwelchen
Vergleichsmessungen.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-08-19 17:27:

Am 19.08.2023 um 12:20 schrieb Arno Welzel:
Helmut Schellong, 2023-07-28 22:07:

Am 28.07.2023 um 15:43 schrieb Arno Welzel:
[...]
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!

Irrelevant. Ich sagte nur \"vielfach schneller\".

Und zu \"Messung\": was genau soll gemessen werden? Worauf bezieht sich
dein \"50-fach schneller\"?

Das hatte ich hier mehrfach umfassend gepostet.
Es ist nun halt vorbei - ich poste das nicht nochmals.

Nein, hast Du nicht:

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

Da steht nichts dazu, worauf sich \"50-fach\" *genau* bezieht.
Irgendwelche ominöse Software mit Daten, die nur Du hast, sind dafür
irrelevant.

Aber gut dann eben nicht. Auch gut.

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

Am 19.08.2023 um 18:37 schrieb Arno Welzel:

Helmut Schellong, 2023-08-19 16:21:

Am 19.08.2023 um 09:53 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.

Die Vorgabe des NIST ist, mehrfach verschachtelte Makros zu benutzen?
Das glaube ich nicht.

Die Vorgabe des NIST ist so, wie ich es oben beschrieben habe.

Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.

Ich rede nicht von Komponenten, sondern das in Form \"mehrfach
verschachtelter Makros\" zu tun.

Das ist auch Vorgabe des NIST.

Makros:
ROTR(x,n) ((x)>>|(x)<<32-)
SUM0(x) (ROTR((x),2)^ROTR((x),13)^ROTR((x),22))

NIST:
ROTR^n (x) = (x >> n) v (x << w - n)
SUM0 (x) = ROTR^2(x) (+) ROTR^13(x) (+) ROTR^22(x)


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 18:40 schrieb Arno Welzel:

Helmut Schellong, 2023-08-19 16:41:

Am 19.08.2023 um 12:10 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 13:07:

Am 29.07.2023 um 12:07 schrieb Thomas Prufer:
On Fri, 28 Jul 2023 00:02:55 +0200, Hanno Foest <hurga-news2@tigress.com> wrote:

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.

Hatte ich auch mal: Systemabstürze nach längerem Arbeiten.

Und memtest fand dann Fehler wenn memtest länger arbeitete... ich vermute
\"thermisch\", also \"irgendwas wird warm\".

Dauerte aber auch >>12h.

Das kann dann eigentlich nichts mehr mit der Temperatur zu tun haben.
Höchstens, daß durch Temperatur >>12h etwas stärker defekt wird.

Ich sehe Zeitkonstanten bei Temperatur von maximal 5 Minuten für CPU.
Je größer der Luftdurchsatz, desto kleinere Zeitkonstanten.

Verwechselst Du da nicht etwas? Je größer der Luftdurchsatz, desto
*länger* dauert es, bis die maximal mögliche Temperatur erreicht ist.

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?

Bei höherem Luftdurchsatz dauert es länger, weil mehr Wärme pro
Zeiteinheit abgeführt wird. Aber Du kannst mir das Gegenteil gerne
vorrechnen.

Zu rechnen gibt es da nichts, sondern es ist einfach physikalisches Verständnis.

Der Wärmewiderstand ist bei 100-fachem Luftdurchsatz vielleicht 20-fach geringer,
so daß ein stationärer Wert vielleicht bereits nach 3 Sekunden erreicht ist.
Bei 1-fachem Luftdurchsatz kann ein stationärer Wert nach 30 Sekunden noch entfernt sein.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 18:43 schrieb Arno Welzel:

Helmut Schellong, 2023-08-19 17:21:

Am 19.08.2023 um 12:16 schrieb Arno Welzel:
[...]
Wenn Du mit die Softare bereitstellst, messe ich gerne nach.

Die hatte ich vor Monaten bereits hier veröffentlicht, per Cloud-Link.
Du müßtest jedoch auch die 110 GB original Daten haben...

Also nicht - auch gut. Dann spare Dir Forderungen nach irgendwelchen
Vergleichsmessungen.

Ich hatte alles geliefert:
8 Fotos, Kommando-Skript, Resultatdatei, etc.

Du liefertest gar nichts, stelltest nur Behauptungen auf.
So ist die Situation oft in dieser NG.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 18:45 schrieb Arno Welzel:

Helmut Schellong, 2023-08-19 17:27:

Am 19.08.2023 um 12:20 schrieb Arno Welzel:
Helmut Schellong, 2023-07-28 22:07:

Am 28.07.2023 um 15:43 schrieb Arno Welzel:
[...]
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!

Irrelevant. Ich sagte nur \"vielfach schneller\".

Und zu \"Messung\": was genau soll gemessen werden? Worauf bezieht sich
dein \"50-fach schneller\"?

Das hatte ich hier mehrfach umfassend gepostet.
Es ist nun halt vorbei - ich poste das nicht nochmals.

Nein, hast Du nicht:

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

Da steht nichts dazu, worauf sich \"50-fach\" *genau* bezieht.
Irgendwelche ominöse Software mit Daten, die nur Du hast, sind dafür
irrelevant.

Aber gut dann eben nicht. Auch gut.

Falsch:
Ich schrieb doch oben: \"Ich habe mehrfach dargestellt,\".
Ich hatte also zuvor bereits mehrfach die Sache mit dem 50-fach umfassend dargestellt.
Mit Zeitnahme-Kommando und allem Drum und Dran.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.08.2023 um 19:36 schrieb Helmut Schellong:

Am 19.08.2023 um 18:37 schrieb Arno Welzel:
Helmut Schellong, 2023-08-19 16:21:

Am 19.08.2023 um 09:53 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.

Die Vorgabe des NIST ist, mehrfach verschachtelte Makros zu benutzen?
Das glaube ich nicht.

Die Vorgabe des NIST ist so, wie ich es oben beschrieben habe.

Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.

Ich rede nicht von Komponenten, sondern das in Form \"mehrfach
verschachtelter Makros\" zu tun.

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   SUM0(x)    (ROTR((x),2)^ROTR((x),13)^ROTR((x),22))

NIST:
   ROTR^n (x) = (x >> n) v (x << w - n)
   SUM0 (x)   = ROTR^2(x) (+) ROTR^13(x) (+) ROTR^22(x)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

Die Inhalte zu den diversen Algorithmen sind komplett verstreut.
Man muß sich alles passende zusammensuchen.
Die Algorithmen sind mittels einer Pseudo-Programmiersprache beschrieben.
Diese ist nicht genormt und daher überall anders.

Der Inhalt ist professionell strukturiert.
Beispielsweise gibt es zu allen verwendeten Symbolen Erklärungslisten.
Es muß folglich annähernd der gesamte Inhalt gelesen werden.

Es werden die Algorithmen der Familie SHA2-### beschrieben.
Zur neuen Familie SHA3 (Keccak) gibt es eine solche PDF m.W. nicht.

Kryptographische Hash-Algorithmen benötigen sehr viel Operationsleistung.
Man sollte bei der Umsetzung in eine geeignete Programmiersprache folglich
nicht irgendwelchen dümmlichen Paradigmen anhängen, die nur schaden.

[1] Verständnis + erfolgreiche Umsetzung.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Arno Welzel schrieb:

Helmut Schellong, 2023-08-19 16:41:

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?

Bei höherem Luftdurchsatz dauert es länger, weil mehr Wärme pro
Zeiteinheit abgeführt wird. Aber Du kannst mir das Gegenteil gerne
vorrechnen.

Bei höherem Luftdurchsatz werden die thermischen Zeitkonstanten
kleiner. Eigentlich trivial.

--
mfg Rolf Bombach