Workstation: erste Tests

Nö, s.u.

Nö,

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

Am 28.07.2023 um 22:40 schrieb Rupert Haselbeck:

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.

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

Das NIST, ein Institut in den USA.

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

Am 28.07.2023 um 22:50 schrieb Rupert Haselbeck:

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

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

Am 28.07.2023 um 23:10 schrieb Rupert Haselbeck:

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

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

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

Das ist eine proplematische Behauptung.

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.

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.

Welche nicht-paralellisierbaren Anwendungen benutzt Du denn so?

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

klingt in meinen Ohren halt wie weinerlicher Abgesang.

Volker

Doch:

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

Ich schrub 'sehr rar, besonders'

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

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

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

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.

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

Man liest sich, Alex.

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

Man liest sich, Alex.

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.

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.

Ich hatte das mit dem da verwechselt:

Gruß Andreas

Am 28.07.2023 um 21:10 schrieb Helmut Schellong:

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[i]= (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[i]= 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[i]+W[i]; 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.

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.

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.

Doch...

Leider doch.

Auch dieses passiert wie beschrieben.

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.

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.

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

Gerrit

Eher mehr... Wir reden hier von mV die übrigbleiben wenn der Kondensator der DRAM-Zelle mit der Leitung zum Leseverstärker verbunden ist.

Ist das nicht vertauscht? Wenn der Kondesnator geladen war müsste die Spannung auf der Leitung doch steigen.

Gerrit