Echter Zufall mit iTSC-counter

Marte Schwarz wrote on 22.09.2026 17:00:

Der Leo hat hier definitiv eine falsche Sichtweise. Er hat den TSC völlig isoliert betrachtet - und das geht hier gar nicht. Ich habe es doch selbst dauernd berichtet, und an Leo gepostet.

Mehr Aufwand bringt in der Regel bessere Ergebnisse. Diese Lotto-Dinger waren ja für 5 DM machbar.

Wahrscheinlich doch. Ich habe festgestellt, daß die Ausgabe auf stdout starke Verzögerungen bewirkt. Diese wirken sehr positiv. Bei der binären Ausgabe von 10000000 Byte jedoch unterblieb die Ausgabe auf stdout. Dadurch bekam ich schlechte Daten.

Richtig, aber meine visuelle Beobachtung war bisher stets korrekt, mein Leben lang. Was ich sah, sah wirklich gut aus, bisher.

Sie sind letztlich nicht nach einem festen Programmablauf ermittelt. Von Bedeutung sind alle Verzögerungen im Programm, besonders die mit Außenwirkung. Bei jedem Stopp im Programm läuft der TSC weiter. Und wenn diese Stopps Zufallsaspekte haben, ist auch der nächste Wert des TSC zufällig.

Ich habe bisher mehrfach angedeutet, daß ich noch nicht fertig bin mit der Arbeit an randtsc. Bevor ich 10 GB Daten als One-Time-Pad konkret verwende, werde ich noch prüfen und forschen müssen. Voraussetzung für weitere Schritte ist mindestens der aktuelle Stand meiner Software.

Die weiteren Sonder-Instruktionen werde ich beizeiten ausprobieren. Für geringere Mengen von echten Zufallszahlen, reicht mein Programm bereits aus. Kann sein, daß ich rdrand für die 10 GB verwende.

Stell Dir ruhig vor, daß ich ein solches Talent tatsächlich habe. Meine Arbeit verlangt ständig nach visuellen Stützen. So arbeite ich schneller und erfolgreicher.

Vor einer Stunde habe ich bei visuellen Sichtungen nach Tests innerhalb von Minuten eine Verflachung der Dynamik nach vielen Daten entdeckt, und Ähnliches. Auch einen Verlust der Zufälligkeit konnte ich entdecken durch 'Kommando args > datei'.

Am 22.09.2026 um 18:32 schrieb Helmut Schellong:

Jetzt reichts! - Ich bin dann 'mal weg und wieder bei den Diplom-Ingenieuren - haha

Richtig, in meinem Programm wirkt ja auch nicht der TSC alleine. Bei Weitem nicht.

Ja, genau richtig. Dennoch läßt das Programm aus seiner eigenen Sicht quasi den TSC weiter hochzählen. Weil das Programm schließlich selbst den nächsten Wert des TSC liest, der dann höher ist, nach jedem Stopp.

Ich schrieb selbst mehrfach, seit Tagen, daß der TSC _unabhängig_ arbeitet. Wieso erklärst Du mir das immer wieder? Der TSC beginnt mit seinem Hochzählen, sobald die CPU ihren Reset nach PowerUp erledigt hat.

Natürlich ist das so. Wenn im Programm ein Stopp kommt, dann bleibt das Programm stehen, aber der TSC tut dies nicht. Und je länger der Stopp ist, desto höher wird der nächste gelesene TSC-Wert.

Leo Baumann wrote on 22.09.2026 18:41:

Eine Verflachung der Dynamik nach vielen Daten ist jedenfalls ein sehr wichtiges Problem für Diplom-Ingenieure.

Beispielsweise Krypto-Pseudo-Zufallszahlen können nach einer bestimmten Anzahl nicht mehr verwendet werden, wegen beginnender Untauglichkeit. Es muß ein Neustart durchgeführt werden, mit neuem Schlüssel.

Bei Auftreten solcher Probleme ziehst Du Dich offenbar zurück.

Am 22.09.2026 um 19:48 schrieb Helmut Schellong:

Du hättest Sozialarbeiter werden sollen!

Leo Baumann wrote on 22.09.2026 19:53:

Dann wärst Du mein Lebenswerk geworden. Ich hätte Dich mit dem Puder des Karl Lagerfeld gepudert und vielem Anderen mehr.

Marte Schwarz wrote on 22.09.2026 17:00:

Beide Ausgaben erfolgten mit abgeschaltetem Rückkopplungs-Delay-Mechanismus (die 0 rechts). Beim oberen Block wurde zum Bildschirm ausgegeben (stdout). Beim unteren Block wurde stdout in eine Datei umgelenkt (randtsc 50 > dez.txt).

Die miese Qualität unten lag bei den Daten für den NIST-Test vor. Die hohe Qualität _oben_ sieht man bereits an den Sprüngen in der Spalte .###., während diese Spalte _unten_ konstant bleibt. Der Unterschied ist absolut gewaltig! Oben Sprünge von bis über 4 Mio Counts, unten im Mittel über 1000 (vierstellig). Tausend Counts Differenz brauchen etwa 300 ns Zeit - viel zu wenig bei höheren Ansprüchen.

Ich habe einen Regler implementiert, der automatisch die Ausgabequalität optimiert. Dies sieht man vorstehend rechts an der wechselnden Bit-Anzahl der Delay-Maske. Das ist notwendig, weil die unterliegende ultra-komplexe Hardware ständig changiert.

All dies stellt einen Beweis dafür dar, daß das Programm Stopps erfährt, während derer der TSC superschnell weiter hochzählt, während das Programm eben steht, oder selbst mit Absicht eine zusätzliche zufällige Verzögerung erzeugt.

Die permanenten 2-stelligen zweifachen Schnaps-Zahlen in den Ausgaben sind für mich bisher unerklärlich! An der Umwandlung (itoa) liegt es nicht.

Erkennst du zB auch, wenn ein Ziffernfolge die Stellen von pi ab Nachkommastelle N ist?

Die Ziffern der Folge sind zufallsverteilt, aber rekonstruierbar, oder?

Thomas Prufer

Visuell gewiß nicht. Es ist aber auch entbehrlich, hier nachzuforschen.

Im Posting: "Echter Zufall mit iTSC-counter - Bericht und Beweis" habe ich das ausführlich erklärt, Schritt für Schritt.

Die Ziffern der Folge sind garantiert nicht rekonstruierbar. Sie kommen schließlich nicht von einem PRNG.

Helmut Schellong wrote on 23.09.2026 23:22:

Den Fehler mit den Doppel-Ziffern konnte ich beseitigen. Es waren jedoch 4 Fehler! Der wirkliche Fehler vom Anfang war: p[0] statt korrekt p[1]. Es wurde eine scheinbare Fehlerbeseitigung vorgenommen, die auch wirkte. Jedoch hatte diese Fehler (die Doppel-Ziffern) ausgelöst. Nach Beseitigung waren die Abtrennungen zu kurz. Es mußten die Längenparameter wieder um 1 erhöht werden. Sapperlot!

Ich kann nun den 2. NIST-Test vorbereiten.

Wegen Fehler-Beseitigung. Die Doppel-Ziffern sind weg, und die Differenz paßt wieder zum TSC-Wert.

Hallo Thomas,

Du schriebst am Thu, 24 Sep 2026 09:49:00 +0200:

Das ist eine äußerst heikle Frage.

So richtig bewiesen ist das "zufallsverteilt" AFAIK zwar nicht, aber es wird allgemein so angenommen. Wenn dem so ist, gibt es aber auch die Möglichkeit, daß _jede_ endliche Ziffernfolge jeder beliebigen Länge in der Folge der Stellen von Pi auftritt, womit die Fragestellung allein an der Angabe der Position "N" hinge und damit gleich die Länge der Vergleichfolge festlegte.

Nebenbei könnte ein Beweis für die Zufallsverteilung der Ziffern von Pi (was dann auch in beliebigen ganzzahligen Basen der Fall sein müßte) bedeuten, daß das wohl auch für jede andere irrationale Zahl gelten müßte, dann halt nur in jeweils anderer Anordnung. Da es ja auch unendlich viele Anordnungsmöglichkeiten für endliche Folgen in einer unendlichen Sequenz gibt, könnte daraus vielleicht sogar ein Zusammenhang zwischen den Mächtigkeiten der Mengen der rationalen und der irrationalen Zahlen gefunden werden, der ja (wieder AFAIK) immer noch strittig ist. Daß die Mächtigkeit der Menge der irrationalen Zahlen die der rationalen übersteigt, wird ja gerne mit einer Art Widerspruchsbeweis durch Angabe einer Anordnungsvorschrift für die rationalen Zahlen und der Angabe einer Abweichenden Stellenfolge einer daraus abgeleiteten "irrationalen" Zahl bewiesen. Sollte dieser Beweis unvollständig sein, könnte das tiefgreifende Wirkungen auf die Mathematik und daraus abgeleitete Anwendungen auf viele Anwendungsgebiete nach sich ziehen. (Sicher ist das eine Privathypothese, aber daß die MAthematik vollständig wäre, behaupten Mathematiker auch nicht. Auch da wird noch viel geforscht, und ein Ende ist nicht in Sicht.)

Sieghard Schicktanz wrote on 25.09.2026 01:52:

Der Counter TSC zählt ja um 1 hoch. Er deckt den kompletten Wert-Bereich 0..2^64-1 ab. In der Praxis müssen folglich _alle_ Werte bis 2^32-1 recht schnell vorkommen.

Helmut Schellong wrote on 24.09.2026 20:51:

Der zweite NIST-Test hat für meine TSC-Zufallszahlen ein super-gutes Ergebnis gebracht! Das beste Ergebnis, das ich bisher bei diesem Test sah. Der p_value hat außerordentlich hohe Werte angenommen. Ich sah nicht selten 0,999 und ähnlich hoch - von 0,01...<1,0 gilt ein Test als bestanden.

Es hat allerdings mehr als 1 Stunde gedauert, bis 1 MB Prüfdaten geschrieben waren. Ich muß folglich den übergroßen Hub der Werte von Lesen zu Lesen (Delay) reduzieren.

Ich habe damit eine neue Art der Erzeugung von echten Zufallszahlen erfunden. Jedenfalls nach meiner Kenntnis.

FILE = /ram/zdat ALPHA = 0.0100 ________________________________________________________________________________

BITSREAD = 1000000 0s = 499156 1s = 500844 BITSREAD = 1000000 0s = 500387 1s = 499613 BITSREAD = 1000000 0s = 500163 1s = 499837 BITSREAD = 1000000 0s = 500338 1s = 499662 BITSREAD = 1000000 0s = 499963 1s = 500037

------------------------------------------------------------------------------ RESULTS FOR THE UNIFORMITY OF P-VALUES AND THE PROPORTION OF PASSING SEQUENCES

------------------------------------------------------------------------------ generator is </ram/zdat>

------------------------------------------------------------------------------ C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 P-VALUE PROPORTION STATISTICAL TEST

------------------------------------------------------------------------------ 1 0 0 0 2 0 0 1 0 1 ---- 5/5 Frequency 0 0 1 0 2 0 1 1 0 0 ---- 5/5 BlockFrequency 0 2 0 1 0 0 1 1 0 0 ---- 5/5 CumulativeSums 0 2 0 1 1 1 0 0 0 0 ---- 5/5 CumulativeSums 1 0 0 0 0 0 1 1 2 0 ---- 5/5 Runs 0 0 0 1 0 0 0 1 3 0 ---- 5/5 LongestRun 1 0 0 1 1 0 0 1 1 0 ---- 5/5 Rank 0 0 1 0 1 0 1 1 0 1 ---- 5/5 FFT 1 0 0 1 1 1 0 1 0 0 ---- 5/5 NonOverlappingTemplate 0 0 3 0 0 2 0 0 0 0 ---- 5/5 NonOverlappingTemplate 0 0 1 0 1 1 0 0 1 1 ---- 5/5 NonOverlappingTemplate ... ...

Helmut Schellong wrote on 25.09.2026 15:37:

Ich konnte den Zeitbedarf des Kommandos 'randtsc' von etwa 1,5 h auf 50 s/MB senken. Das sind etwa 1,7 GB pro Tag, bei einem CPU-Kern. Die Qualität konnte ich durch Verringern der Bitbreite halten - immer noch 0 NIST-Fehler. Der Mittelwert der p_values ist im Überblick geringer. Der übergroße Hub zuvor hatte durchaus eine positive Wirkung auf die Qualität.

Das Projekt ist nun vorläufig beendet. Ich kann das Kommando nun normal nutzen.

Es sind wirklich echte Zufallszahlen! Die erste vom Kommando gelesene Zahl ist sowieso eine echte Zufallszahl. Diese echte Zufallszahl bestimmt hauptsächlich die Dauer der Kommando-Verzögerung. Folglich ist die nächste gelesene Zahl erneut eine echte Zufallszahl, usw.

Zudem beaufschlagt die gesamte Hardware+Software des Computers dem Kommando Verzögerungen. Diese addieren sich zu der internen Verzögerung des Kommandos, und sie können größer sein als die interne Verzögerung des Kommandos. Es sind entsprechende Veränderungen an den ausgegebenen Differenzen und der geregelten Bitbreite erkennbar und eindeutig zuzuordnen.

Das Kommando ist nicht deterministisch in Bezug auf die gelesenen TSC-Werte. Ich kann jeglichen Ausgabe-Strom nicht gezielt wiederholen, alle längeren sind tendenziell einzigartig.

Am 25.09.2026 um 23:13 schrieb Helmut Schellong:

Für welchen Einsatzbereich planst du diesen Zufallsgenerator?Für ein Spiel oder eine Simulation (wo Performance wichtig ist und Algorithmen wie Xorshift oder Mersenne-Twister perfekt sind)?

Für ein Sicherheitsprojekt / Kryptografie (wo PRNGs mit RDTSC-Seed tabu sind und man stattdessen RDRAND oder Betriebssystem-Entropie wie /dev/urandom nutzen muss)?

:)

Am 25.09.2026 um 23:13 schrieb Helmut Schellong: [...]

Es macht mir keinen Spaß auf kleine Leute herumzuhacken, aber Du bist ein Geisterfahrer, der gegen alle AI der Welt anfährt.

:)

Ja.

Deshalb stellte ich sie auch:-)

Thomas Prufer