Workstation: erste Tests...

[Rupert Haselbeck]

Helmut Schellong schrieb:

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

Wozu? Es ist völlig belanglos, ob das nun drei, fünf oder sieben Minuten
oder auch eine Stunde dauert

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.

Das mag sein. In der Wirklichkeit gibt es aber keine solchen Kategorien

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

Warum?

Beantworte ich nicht.

Du verstehst deine eigenen Behauptungen nicht mehr?

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

Schon klar. Du wolltest halt ein Spielzeug ohne besonderen
Zweck. Das ist aber doch wirklich kein Problem, für das du dich
irgendwie rechtferigen müsstest. Der eine hat seine Katze, der andere
liest den großen Brockhaus und du hast halt deine \"Workstation\". Alles
kein Problem

MfG
Rupert

 

[Wolfgang Allinger]

On 28 Jul 23 at group /de/sci/electronics in article ua0603$mmv$1@news.bawue.net
<gerrit@laosinh.s.bawue.de> (Gerrit Heitsch) wrote:

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,

Nö, s.u.

> Auslesen ist destruktiv.

Nö,

Das Zurückschreiben ist allerdings im RAM integriert und passiert
automatisch am Ende des Zugriffs.
Nö,

Nö, die Ladung auf den Gates verschwindet, egal ob man sie ausliest oder
nicht. Auch beim auslesen verschwindet nix.
Allerding nach einigen msec. Desterwegen muss man refresh cycles machen.
Musste man früher im BIOS extra anpassen. Hab vergessen, wie das genau
ging, habs aber mal für CP/M und BIOSe fürn 8080 und Z80 programmiert samt
Z80 IR-gesteuertem DMA Transfer für 8\" Floppies gemacht.

Leseschwäche?

Ich schrubtete:
--x8--
Nicht nur da, gabs \'verduftende\' Bits, die wiederbelebt werden müssen.
Ist also gängiges Problem bzw. Verfahren.

Bei dynamischen RAM, müssen alle paar msec die Infos \'refreshed\' werden.
^^^^^^^^^^^^^^^!!!aka DRAM!!! x)

Bei auf Floating Gates gespeicherten Daten gibbet den mehr oder weniger
schnellen Verschwindi.BUS Effekt.
Auch MagTapes müssen regelmäßig kontrolliert werden.
--8x--

x) nun noch extra unterstrichen

Sachens nit dä Jong es schäl, dä lieve Jong siecht nur schläch!


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Sieghard Schicktanz]

Hallo Wolfgang,

Du schriebst am Thu, 27 Jul 2023 08:25:00 -0400:

Nicht nur da, gabs \'verduftende\' Bits, die wiederbelebt werden müssen.
Ist also gängiges Problem bzw. Verfahren.
....
Dauerhafte Speicher sind sehr rar, besonders wenn Dauerhaft mehrere
Jahre, Jahrzehnte...Jahrtausende bedeutet.
Jajaja, ich kenne Höhlenmalerei, Steintafeln...

Auch da gibt\'s Verluste.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Helmut Schellong]

Am 28.07.2023 um 22:40 schrieb 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

Das Thema wurde im Thread bereits mehrfach abgehandelt.
Gähn.
Ich habe selbst gesagt, daß das nur ein Praxis-Beweis ist.
Ein theoretisch-mathematischer Beweis sei das nicht.

Die statistisch herzuleitende Wahrscheinlichkeit steigt, schreibst Du.
Ja, die steigt billionen- oder trillionen-fach.

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

Belehre mich nicht hierzu.
Ich habe diese Algorithmen implementiert.
Ich lach\' mich schräg.

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?

Das NIST, ein Institut in den USA.

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.

Bemühe Dich nicht.
Ich weiß besser, wie es bei diesem Thema läuft.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 22:50 schrieb Rupert Haselbeck:

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

Der Testlauf ist deterministisch, wohldefiniert, beliebig wiederholbar,
und für jeden nachvollziehbar.
Es ist ein Praxis-Beweis.

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

Denk mal an - so habe ich das gar nicht gemeint! Falsche Ebene.
Aber so etwas kannst Du ja auch nicht erkennen.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 28.07.2023 um 23:10 schrieb Rupert Haselbeck:

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

Wozu? Es ist völlig belanglos, ob das nun drei, fünf oder sieben Minuten oder auch eine Stunde dauert

Du beschimpfst dadurch alle Benchmarks der Welt als völlig belanglos.
Und bloße Vermutungen sind für Dich höherwertig als Messungen.

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.

Das mag sein. In der Wirklichkeit gibt es aber keine solchen Kategorien

Doch, gibt es.
Ich habe die Kategorien der Wirklichkeit in Algorithmen umgesetzt.
Beispielsweise die Pattern, die BRE, die ERE, ...

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

Warum?

Beantworte ich nicht.

Du verstehst deine eigenen Behauptungen nicht mehr?

Du verstehst nicht den sprachlichen Vorgang.
Es handelt sich um einfach formuliertes Deutsch.

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

Schon klar. Du wolltest halt ein Spielzeug ohne besonderen
Zweck.

Das ist eine proplematische Behauptung.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Volker Bartheld]

On Fri, 28 Jul 2023 20:44:43 +0200, Rolf Bombach wrote:

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.

Du unterstellst, dieses Performancemerkmal hätte in Alleinstellung 2023
irgendwelche Relevanz. Hat sie nicht. Genausogut könnte man die CPUs
wiegen und feststellen, sie seien seit 1970 eigentlich nicht signifikant
leichter geworden.

Ausserdem mag es dich überraschen, dass es sehr viele, auch
prozentual, User gibt, die nicht Cryptos schürfen oder CERN-Daten
auswerten.

Aber 3-999 Browsertabs offenhaben, nebenher ein wenig Musik streamen,
vielleicht noch an einem Officedokument basteln und das Ganze
vielleicht im Homeoffice mit Remote Session. Da mag es mich i. d. T.
überraschen, wenn ein vorsintflutliches System mit derselben
Single-Core-Performance im Vergleich zu einer modernen CPU auch nur
einen geölten Hering vom Teller zieht.

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

Welche nicht-paralellisierbaren Anwendungen benutzt Du denn so?

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.

Wenn LTSpice ausschließlich und nur das ist, was Du tust, dann bleib bei
(D)einem Rechner mit möglichst hoher Single-Core-Leistung. Das war
jetzt einfach. Dein

Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt
es keine wirklich grossen Sprünge mehr.

klingt in meinen Ohren halt wie weinerlicher Abgesang.


Volker

 

[Michael Schwingen]

On 2023-07-28, Wolfgang Allinger <all2001@spambog.com> wrote:

Nö, s.u.

Auslesen ist destruktiv.

Nö,

Das Zurückschreiben ist allerdings im RAM integriert und passiert
automatisch am Ende des Zugriffs.
Nö,

Doch:

https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Operations_to_read_a_data_bit_from_a_DRAM_storage_cell

Nö, die Ladung auf den Gates verschwindet, egal ob man sie ausliest oder
nicht. Auch beim auslesen verschwindet nix.

Beim Auslesen fliesst die Ladung aus der Zelle auf die Bitleitung, die Zelle
verliert deutlich Ladung (in Richtung VCC/2).

\"Since the capacitance of the bit-line is typically much higher than the
capacitance of the storage cell, the voltage on the bit-line increases very
slightly if the storage cell\'s capacitor is discharged and decreases very
slightly if the storage cell is charged\" bedeutet, daß in der Zelle
praktisch nichts vom ursprünglichen Pegel übrig bleibt.

Sobald die Leseverstärker den Zustand gelatcht haben, wird die Zelle
mit dem richtigen (gelesenen) Pegel aufgefrischt.

Der langsame Ladungsverlust, der einen Refresh nach typisch einigen 10 ms
benötigt, ist unabhängig davon.

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

 

[Wolfgang Allinger]

On 28 Jul 23 at group /de/sci/electronics in article 20230728221846.596f4fa8@Achmuehle.WOR
<Sieghard.Schicktanz@SchS.de> (Sieghard Schicktanz) wrote:

Hallo Wolfgang,

Du schriebst am Thu, 27 Jul 2023 08:25:00 -0400:

Nicht nur da, gabs \'verduftende\' Bits, die wiederbelebt werden müssen.
Ist also gängiges Problem bzw. Verfahren.
...
Dauerhafte Speicher sind sehr rar, besonders wenn Dauerhaft mehrere
Jahre, Jahrzehnte...Jahrtausende bedeutet.
Jajaja, ich kenne Höhlenmalerei, Steintafeln...

Auch da gibt\'s Verluste.

Ich schrub \'sehr rar, besonders\'



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 29 Jul 23 at group /de/sci/electronics in article slrnuc9mlq.3qsag.news-1513678000@a-tuin.ms.intern
<news-1513678000@discworld.dascon.de> (Michael Schwingen) wrote:

On 2023-07-28, Wolfgang Allinger <all2001@spambog.com> wrote:

Nö, s.u.

Auslesen ist destruktiv.

Nö,

Das Zurückschreiben ist allerdings im RAM integriert und passiert
automatisch am Ende des Zugriffs.
Nö,

Doch:

https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Operations_to_rea
d_a_data_bit_from_a_DRAM_storage_cell

Nö, die Ladung auf den Gates verschwindet, egal ob man sie ausliest oder
nicht. Auch beim auslesen verschwindet nix.

Beim Auslesen fliesst die Ladung aus der Zelle auf die Bitleitung, die Zelle
verliert deutlich Ladung (in Richtung VCC/2).

\"Since the capacitance of the bit-line is typically much higher than the
capacitance of the storage cell, the voltage on the bit-line increases very
slightly if the storage cell\'s capacitor is discharged and decreases very
slightly if the storage cell is charged\" bedeutet, daß in der Zelle
praktisch nichts vom ursprünglichen Pegel übrig bleibt.

Sobald die Leseverstärker den Zustand gelatcht haben, wird die Zelle
mit dem richtigen (gelesenen) Pegel aufgefrischt.

Der langsame Ladungsverlust, der einen Refresh nach typisch einigen 10 ms
benötigt, ist unabhängig davon.

Danke für die Erklärung, leuchtet ein, aber soweit hatte ich bisher nie
ins DRAM schauen müssen. Ich hatte nur die Sache mit den refresh auf dem
Tablett.


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

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



Thomas Prufer

 

[Helmut Schellong]

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.

Es ist bekannt, daß ganze Geräte meistens nach 30..45 Minuten durcherwärmt sind.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Alexander Schreiber]

Andreas Fecht <forum@aftec.de> wrote:

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

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


Das ist aber nur Maskerade!

Die beiden Ordner heißen auf Systemebene anders:

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

Lustigerweise ist es genau _andersrum_. Die Verzeichnisse heissen
sehr wohl z.B. \"C:\\Program Files\" - NTFS hat mit langen Dateinamen
und auch Leerzeichen im Dateinamen kein Problem. Die kurzen Namen wie
C:\\PROGRA~1 sind 8+3 (Name+Erweiterung) von FAT, eine vom Betriebssystem
künstlich zur Verfügung gestellte Krücke für ranzlige alte Software,
die von FAT (und den entsprechenden Grenzen) ausgeht und mit langen
Dateinamen nicht umgehen kann.

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

Tut es eben nicht. \"dir /X\" zeigt den Kurznamen an - obige Krücke.

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison

 

[Alexander Schreiber]

Arno Welzel <usenet@arnowelzel.de> wrote:

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

Neugierige Frage: sind das stripped oder unstripped binaries? Unstripped
lässt sich (aufgrund der textartigen Natur der Symboltabellen) gut
komprimieren.

Man liest sich,
Alex.
--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison

 

[Alexander Schreiber]

Hanno Foest <hurga-news2@tigress.com> wrote:

Am 26.07.23 um 14:53 schrieb Alexander Schreiber:

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

Ich konnte mal einen Blick auf einen Server mit schweren
Speicherproblemen werfen, der loggte ECC Fehler mit maximaler Lograte.
War aber dennoch gut benutzbar. Die Kollegen hatten Nerven: Die haben
mit dem Speichertausch bis zum nächsten Wartungsfenster gewartet.

Kommt drauf an, was die Software macht. Wir hatten Software, die sehr
empfindlich auf einen Einbruch der verfügbaren Speicherbandbreite
reagiert. Wenn da tasks langsamer wurden, war das meist einer von
zwei Gründen:
- auf der Maschine ist ein Video-Transcoder angelaufen, die fressen
Speicherbandbreite ohne Ende
- die ECC-error-corrected Zähler rotieren mit hoher Geschwindigkeit
(\"counter goes brrrrrr\")

Man liest sich,
Alex.

--
\"Opportunity is missed by most people because it is dressed in overalls and
looks like work.\" -- Thomas A. Edison

 

[Andreas Fecht]

Am 29.07.2023 um 13:03 schrieb Alexander Schreiber:

Andreas Fecht <forum@aftec.de> wrote:

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

Tut es eben nicht. \"dir /X\" zeigt den Kurznamen an - obige Krücke.

Ich hatte das mit dem da verwechselt:

https://answers.microsoft.com/en-us/windows/forum/all/locale-names-of-folders/7e2dd3d0-e53a-4dfb-9175-afbac65f13f7

Das hat schon viele Leute verwirrt!

Gruß Andreas

 

[Helmut Schellong]

Am 28.07.2023 um 21:10 schrieb 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:
[...]

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.

https://magentacloud.de/s/27Ax6EEALNjYqTD

Ein Ausschnitt von unter dem Link:
==================================================================================
# define CH(x,y,z) (((x)&)^(~(x)&(z)))
# define MAJ(x,y,z) (((x)&)^((x)&(z))^(&(z)))
# define ROTR(x,n) ((x)>>|(x)<<32-)
# define SUM0(x) (ROTR((x),2)^ROTR((x),13)^ROTR((x),22))
# define SUM1(x) (ROTR((x),6)^ROTR((x),11)^ROTR((x),25))
# define S0(x) (ROTR((x),7)^ROTR((x),18)^((x)>>3))
# define S1(x) (ROTR((x),17)^ROTR((x),19)^((x)>>10))


static void sha_256(byte *buf) //jeweils 64 Byte = 512 Bit
{
UNS4 W[64];
UNS4 a,b,c,d,e,f,g,h, t1,t2;
int i, j;

for (j=i=0; i<16; i+=1,j+=4) {
W= (UNS4)buf[j+3]<< 0|(UNS4)buf[j+2]<< 8|
(UNS4)buf[j+1]<<16|(UNS4)buf[j+0]<<24;
}
for (i=16; i<64; ++i) {
a= W[i-2]; e= W[i-15];
W= S1(a)+W[i-7]+S0(e)+W[i-16];
}
a=shaH0, b=shaH1, c=shaH2, d=shaH3, e=shaH4, f=shaH5, g=shaH6, h=shaH7;
for (i=0; i<64; ++i) {
t1= h+SUM1(e)+CH(e,f,g)+shaK+W;
t2= SUM0(a)+MAJ(a,b,c);
h=g, g=f, f=e, e=d+t1;
d=c, c=b, b=a, a=t1+t2;
}
shaH0+=a, shaH1+=b, shaH2+=c, shaH3+=d;
shaH4+=e, shaH5+=f, shaH6+=g, shaH7+=h;
return;
}
==================================================================================
Es ist erkennbar, wie extrem die Eingangsdaten (buf, W[]) durchgemischt werden.
Dies beginnt in der zweiten Schleife.
Der Hash läuft in shaH0..shaH7 (32x8 = 256 bit).
In der letzten Schleife werden shaK[] und W[] hinzu addiert.
shaK ist ein Array aus 64 kryptographischen Konstanten.
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 29.07.2023 um 13:06 schrieb Alexander Schreiber:

Arno Welzel <usenet@arnowelzel.de> wrote:
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

Neugierige Frage: sind das stripped oder unstripped binaries? Unstripped
lässt sich (aufgrund der textartigen Natur der Symboltabellen) gut
komprimieren.

Das hatte ich bereits angemerkt (25.07.2023, 23:03).

|Ja, ist so, man sollte Executables auch /strippen/.
|Es können mitunter auch sehr viele Textteile darin sein, als Konstanten.
|Kann auch sein, daß 64Bit-Exe besser komprimierbar sind.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Axel Berger]

Alexander Schreiber wrote:

NTFS hat mit langen Dateinamen
und auch Leerzeichen im Dateinamen kein Problem.

NTFS nicht und pointee-clickee auch nicht. Aber sowie man mit Dateien
ersthaft arbeiten will, geht der Ärger los.

Und die \"neu ist immer besser\" Jünger, die den Verzicht auf Leerzeichen
für vollkommen unzumutbar halten, sehen dann auf einmal gar kein Problem
mit komplexen und fehlerträchtigen Regeln, was alles und wie genau zu
quoten sei, teilweise geschachtelt.

Ich nehme für mich lieber die ganz einfache Regel und verzichjte auch
alle diese Komplexizitäten.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Gerrit Heitsch]

On 7/28/23 23:32, Wolfgang Allinger wrote:

On 28 Jul 23 at group /de/sci/electronics in article ua0603$mmv$1@news.bawue.net
gerrit@laosinh.s.bawue.de> (Gerrit Heitsch) wrote:

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,

Nö, s.u.

Doch...

Auslesen ist destruktiv.

Nö,

Leider doch.

Das Zurückschreiben ist allerdings im RAM integriert und passiert
automatisch am Ende des Zugriffs.
Nö,

Auch dieses passiert wie beschrieben.

Nö, die Ladung auf den Gates verschwindet, egal ob man sie ausliest oder
nicht. Auch beim auslesen verschwindet nix.

Doch, beim Auslesen verschwindet die Ladung in der Zelle. Wir reden hier
von DRAM, nicht von EPROMs. Der FET schaltet den, im Vergleich zum Rest,
sehr kleinen Kondensator der DRAM-Zelle auf die Leitung zum
Leseverstärker. Dadurch bricht die Spannung im Kondensator auf so
ziemlich nichts zusammen. Der Leseverstärker muss jetzt erkennen ob der
Kondensator geladen war oder nicht. Am Ende des Zyklus muss aber der
Kondensator wieder befüllt werden, das Auslesen geht nur einmal. Das
passiert nach dem Ende des Zugriffes und ist der Grund warum ein DRAM
etwas Zeit braucht bis der nächste komplette Zugriff erlaubt ist.


> Allerding nach einigen msec. Desterwegen muss man refresh cycles machen.

Ja... und was macht ein Refresh? Zelle auslesen, dabei deren Inhalt
zerstören und zurückschreiben. Es wird dabei immer eine komplette Zeile
(Row) ausgelesen und zurückgeschrieben.

Bei auf Floating Gates gespeicherten Daten gibbet den mehr oder weniger
schnellen Verschwindi.BUS Effekt.

Flaoting Gates benutzt man bei EPROMs, EEPROMs und Flash, nicht bei DRAM.

Gerrit