0.1 ppm und besser

Leo Baumann

unread,

Jul 11, 2022, 10:00:03 AM7/11/22

to

haha,

man kann etliche tausend Euro ausgeben um einen Frequenzzähler oder
einen Generator zu bekommen, der genauer als 0.1 ppm bei 10 MHz ist.-

Bei mir geht das so:

1.) den 41 Jahre alten Frequenzzähler und das Radio JRC 545 DSP mit TCXO
und DDS20-Board warmlaufen lassen

2.) Computer mit kalibrierter Soundkarte mit dem Programm Spectrum starten

3.) auf dem Radio bei 10 MHz dass DDS20-Signal (CW, 1 kHz BFO) beobachten

4.) Beim DDS20-Board per Tastsatur exakt auf 1 kHz +- 0 einstellen

5.) mit der Halogen Tischleuchte den Frequenzzähler leicht erwärmen bis
er exakt 10 MHz +- 0.5 Hz anzeigt

6.) jetzt umstöpseln und Frequenz des Prüflings messen

Die ganze Aktion dauert 30 Minuten ohne die Warmlaufzeit der Geräte.

Nein, ich werde kein Geld aus dem Fenster werfen ...

:)

Arno Welzel

unread,

Jul 12, 2022, 3:47:44 AM7/12/22

to

Leo Baumann:

> 2.) Computer mit kalibrierter Soundkarte mit dem Programm Spectrum starten

Was ist eine "kalibrierte Soundkarte"? Wie wird die kalbriert?

--
Arno Welzel
https://arnowelzel.de

Leo Baumann

unread,

Jul 12, 2022, 6:17:52 AM7/12/22

to

Am 12.07.2022 um 09:47 schrieb Arno Welzel:
> Was ist eine "kalibrierte Soundkarte"? Wie wird die kalbriert?

Zunächst mal kannst Du mit diesem Programm:

www.leobaumann.de/newsgroups/SoundSpeed.zip

den Fehler Deiner Soundkarte prüfen.
Bedienungsanleitung lesen!

:)

Arno Welzel

unread,

Jul 13, 2022, 10:40:31 AM7/13/22

to

Leo Baumann:

Welche Bedienungsanleitung? In der ZIP-Datei gibt es keine, nur ein
Programm.

Leo Baumann

unread,

Jul 13, 2022, 10:44:48 AM7/13/22

to

Ah, Entschuldigung. Das Programm WAR 'mal im Internet und auf der
Webseite stand die Bedienungsanleitung.-

Man soll das Programm lange laufen lassen - so 32 Stundne oder so - Je
länger das läuft, um so genauer der Wert des prozentualen Timingfehlers
der Soundkarte.

Grüße

Joerg Niggemeyer

unread,

Jul 13, 2022, 11:31:10 AM7/13/22

to

In message <tamlou$5acs$1...@solani.org>

Leo Baumann <i...@leobaumann.de> wrote:

> Man soll das Programm lange laufen lassen - so 32 Stundne oder so - Je
> länger das läuft, um so genauer der Wert des prozentualen Timingfehlers
> der Soundkarte.

Klingt ja unheimlich logisch.....
Hast du mal das was deine SK an F misst mit einem Specki
oder scope FFT verglichen??

--

Leo Baumann

unread,

Jul 13, 2022, 11:45:10 AM7/13/22

to

Nein, ich habe damals dieses Progrämmchen irgendwo her empfohlen
bekommen, ich glaube von USA-Jörg.

Der Timing-Fehler meiner Soundkarte ist so klein, der kann mit Speki
oder Scope nicht gemessen werden.

Ich habe einen HP Z240, das göttliche an der Workstation liegt im
Detail, also auch im Timing.

Es soll aber PC-Boards geben, die fürchterlich sind.

Grüße

Leo Baumann

unread,

Jul 13, 2022, 12:51:42 PM7/13/22

to

Am 13.07.2022 um 17:31 schrieb Joerg Niggemeyer:

Wenn ich meinen R&S RTB2002-100 MHz mit 2.5 ppm Zeitbasis schon hätte
könnte ich das so eben messen bei 1 KHz wie genau das Programm
SpecLab.exe bei mir auf dem HP ist. Dann würde das DSO 2.5 mHz auflösen.

Mit meinem aktuellen 41 Jahre alten analogen Oszi geht das nicht. :)

Grüße

Helmut Wabnig

unread,

Jul 13, 2022, 1:03:13 PM7/13/22

to

On Wed, 13 Jul 2022 17:45:04 +0200, Leo Baumann <i...@leobaumann.de>
wrote:

Ich habs bemerkt beim Musikeditieren von Microtuning.
Soundkarten haben verschiedene Quarze für die jeweiligen Sampleraten.
Die Fehler in der Tonhöhe waren zwar gering, aber doch merkbar.
Ausreißer gibts mit deutlichen Tonhöhenfehlern.

w.

Michael Schwingen

unread,

Jul 13, 2022, 1:47:31 PM7/13/22

to

On 2022-07-13, Leo Baumann <i...@leobaumann.de> wrote:
> Wenn ich meinen R&S RTB2002-100 MHz mit 2.5 ppm Zeitbasis schon hätte
> könnte ich das so eben messen bei 1 KHz wie genau das Programm
> SpecLab.exe bei mir auf dem HP ist. Dann würde das DSO 2.5 mHz auflösen.
>
> Mit meinem aktuellen 41 Jahre alten analogen Oszi geht das nicht. :)

Doch: XY-Modus gegen einen genauen Referenzoszillator (Rb, Cs oder GPS).
Beim Abstimmen des OCXO im Frequenzzähler reagiert das deutlich
empfindlicher als die letzte Stelle des Zählers, und man sieht viel
schneller, ob sich was bewegt und in welche Richtung man abstimmen muss.

cu
Michael

Arno Welzel

unread,

Jul 13, 2022, 3:24:55 PM7/13/22

to

Leo Baumann:

Aha. Und wie genau misst das Ding den Timingfehler? Muss man da an der
Soundkarte irgendwas anschließen?

Leo Baumann

unread,

Jul 13, 2022, 4:22:45 PM7/13/22

to

Am 13.07.2022 um 21:24 schrieb Arno Welzel:
> Aha. Und wie genau misst das Ding den Timingfehler? Muss man da an der
> Soundkarte irgendwas anschließen?

Ich habe keine Ahnung was der da programmiert hat. Angeblich ist das
sehr, sehr, sehr genau. Man muss nichts anschließen.

Lass' 'mal laufen und poste das Ergbnis, bitte.

:)

Arno Welzel

unread,

Jul 14, 2022, 5:06:42 AM7/14/22

to

Leo Baumann:

Am Anfang:

0,059454772848334%

Und je länger es läuft, desto niedriger wird der Wert:

0,022583639076850%
0,020594552362853%
0,019504505954579%
0,008942889900956%
0,007660720666631%
0,006428961625946%
...

Hardware ist Realtek ALC889, der als Onboard-Sound-Lösung von ASUS mit
dem Namen "SupremeFX III" bezeichnet wird. Zumindest subjektiv klingt
das Ding über Kopfhörer auch sehr gut und nicht schlechter als manche
dedizierte Soundkarte, die ich in früheren PCs hatte.

Leo Baumann

unread,

Jul 14, 2022, 6:27:53 AM7/14/22

to

Ja, in meinem HP ist auch Sound von Realtek. Brauch'ste nicht messen ist
hinreichend genau ...

Grüße

Leo Baumann

unread,

Jul 14, 2022, 7:09:25 AM7/14/22

to

Am 14.07.2022 um 11:06 schrieb Arno Welzel:

Deine letzte Prozentzahl bedeuten ja schon einen Timingfehler Deiner
Soundkarte von 0.064 ppm ...

:)

Helmut Schellong

unread,

Jul 14, 2022, 7:25:20 AM7/14/22

to

Leo Baumann

unread,

Jul 14, 2022, 7:33:20 AM7/14/22

to

Am 14.07.2022 um 13:25 schrieb Helmut Schellong:
> 0,001% ist 10^-5
> 0,01 ppm ist 10^-8

Ich bin noch nicht ausgeschlafen. Der erste Kaffee wirkt noch nicht. Ich
habe mich mit Promille vertan.

haha - :)

Leo Baumann

unread,

Jul 14, 2022, 7:56:08 AM7/14/22

to

Am 14.07.2022 um 11:06 schrieb Arno Welzel:

Also, wenn Du mit Deiner Soundkarte ein NF-Spektrum ansiehst sind die
angezeigten Frequenzen um +-0.0064 % falsch. Bei einer 1 kHz
Spektrallinie sind das also 64 Milliherz.

:)

Joerg Niggemeyer

unread,

Jul 14, 2022, 8:57:27 AM7/14/22

to

In message <jja4l0...@mid.individual.net>

Arno Welzel <use...@arnowelzel.de> wrote:

> Am Anfang:

> 0,059454772848334%

> Und je länger es läuft, desto niedriger wird der Wert:

> 0,022583639076850%
> 0,020594552362853%
> 0,019504505954579%
> 0,008942889900956%
> 0,007660720666631%
> 0,006428961625946%
> ...

Benötigt die SW Internetzugang (NTP) ?

--

Leo Baumann

unread,

Jul 14, 2022, 9:02:51 AM7/14/22

to

Das weiß ich nicht. Ich hatte SoundSpeed.zip heruntergeladen und
abgespeichert. Die zugehörige (amerikanische) Internetseite mit der
Beschreibung finde ich aber nicht wieder.

Wenn die Internet braucht, dann merke ich das nicht, weil ich
hervorragendes Dauer-Internet habe 1000/50 MBit/s.

Grüße

Rolf Bombach

unread,

Jul 14, 2022, 10:00:35 AM7/14/22

to

Arno Welzel schrieb:

>
> Am Anfang:
>
> 0,059454772848334%
>
> Und je länger es läuft, desto niedriger wird der Wert:
>
> 0,022583639076850%
> 0,020594552362853%
> 0,019504505954579%
> 0,008942889900956%
> 0,007660720666631%
> 0,006428961625946%
> ...

Möglicherweise stehst du kurz vor der Entdeckung der Allan-Varianz.

https://en.wikipedia.org/wiki/Allan_variance

Schau mal, ob es langfristig wieder ansteigt.

> Hardware ist Realtek ALC889, der als Onboard-Sound-Lösung von ASUS mit
> dem Namen "SupremeFX III" bezeichnet wird. Zumindest subjektiv klingt
> das Ding über Kopfhörer auch sehr gut und nicht schlechter als manche
> dedizierte Soundkarte, die ich in früheren PCs hatte.

Hmm, bei mir nicht einfach rauszukriegen. Jedenfalls gibt es vereinzelt
MoBos mit verstärktem Audio-Teil; ich hab keins, da das für meine Ohren
keinen Sinn ergibt.

--
mfg Rolf Bombach

Leo Baumann

unread,

Jul 14, 2022, 10:15:14 AM7/14/22

to

Am 14.07.2022 um 16:00 schrieb Rolf Bombach:
> Möglicherweise stehst du kurz vor der Entdeckung der Allan-Varianz.

Haha - schreib das dem amerikanischen Programmierer von SoundSpeed.exe.

:)

Leo Baumann

unread,

Jul 14, 2022, 10:33:36 AM7/14/22

to

Am 14.07.2022 um 16:00 schrieb Rolf Bombach:

> Hmm, bei mir nicht einfach rauszukriegen. Jedenfalls gibt es vereinzelt
> MoBos mit verstärktem Audio-Teil; ich hab keins, da das für meine Ohren
> keinen Sinn ergibt.

Es gibt aber so schöne Programme wie SpecLab.exe, das kann man zum
Messen gebrauchen. Die zeigen Peaks im Spektrum mit 1/1000 Hz an.

:)

Michael Schwingen

unread,

Jul 14, 2022, 1:21:51 PM7/14/22

to

On 2022-07-14, Rolf Bombach <rolfnosp...@invalid.invalid> wrote:
> Hmm, bei mir nicht einfach rauszukriegen. Jedenfalls gibt es vereinzelt
> MoBos mit verstärktem Audio-Teil; ich hab keins, da das für meine Ohren
> keinen Sinn ergibt.

Ich habe allerdings noch auf keinem Mobo und keiner Soundkarte etwas anderes
als einen Standardquarz(-oszillator) gesehen. Wo da eine Genauigkeit besser
als ein paar ppm (eher ein paar -10 ppm) herkommen soll, ist mir nicht klar.

Ebensowenig ist mir klar, wie dieses Tool das messen will, ohne eine
genauere Referenz heranzuziehen.

cu
Michael

Michael Schwingen

unread,

Jul 14, 2022, 1:23:15 PM7/14/22

to

On 2022-07-14, Leo Baumann <i...@leobaumann.de> wrote:
> Es gibt aber so schöne Programme wie SpecLab.exe, das kann man zum
> Messen gebrauchen. Die zeigen Peaks im Spektrum mit 1/1000 Hz an.

Auflösung != Genauigkeit. Wo kommt bei diesem soundspeed.exe die genaue
Referenz für die Messung her?

cu
Michael

Leo Baumann

unread,

Jul 14, 2022, 1:29:49 PM7/14/22

to

Ich vermute Internet. Aber ich kann die Website des Programms mit der
Beschreibung in USA nicht wiederfinden.

Grüße

Leo Baumann

unread,

Jul 14, 2022, 3:53:28 PM7/14/22

to

Am 14.07.2022 um 19:23 schrieb Michael Schwingen:

https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

Grüße

Leo Baumann

unread,

Jul 14, 2022, 4:40:21 PM7/14/22

to

Am 13.07.2022 um 16:40 schrieb Arno Welzel:

> Welche Bedienungsanleitung? In der ZIP-Datei gibt es keine, nur ein
> Programm.

https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

Grüße

Sieghard Schicktanz

unread,

Jul 14, 2022, 5:43:06 PM7/14/22

to

Hallo Arno Welzel,

Du schriebst am Thu, 14 Jul 2022 11:06:40 +0200:

> > Lass' 'mal laufen und poste das Ergbnis, bitte.
>
> Am Anfang:
>
> 0,059454772848334%
>
> Und je länger es läuft, desto niedriger wird der Wert:

Das ist verdächtig - da wird doch nicht etwa die _integrale_ Abweichung
über die gesamte Meßzeit angegeben? (Wobei sich dann auch noch fragt,
was da als Referenz benutzt wird.)
Bei (relativ kurzdauernden) Messungen ist aber eher die Stabilität der
Werte relevant, was heißt, daß die bei solchen Änderungen _schlecht_
ist. Sind die gemessenen Werte stabil, sollte sich an den relativen
Abweichungen eher wenig ändern, lediglich Schwankungen im Rahmen der
atatistschen Abweichungen aufgrund des Probenumfangs.

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

Leo Baumann

unread,

Jul 14, 2022, 9:20:08 PM7/14/22

to

Am 14.07.2022 um 19:21 schrieb Michael Schwingen:
> Ich habe allerdings noch auf keinem Mobo und keiner Soundkarte etwas anderes
> als einen Standardquarz(-oszillator) gesehen. Wo da eine Genauigkeit besser
> als ein paar ppm (eher ein paar -10 ppm) herkommen soll, ist mir nicht klar.
>
> Ebensowenig ist mir klar, wie dieses Tool das messen will, ohne eine
> genauere Referenz heranzuziehen.

Hier ein paar Worte des Programmierers zu dem Programm SoundSpeed.exe:

https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

Da steht was von der Systemzeit, die während der Messung übers Internet
synchronisiert sein muss.

Ich habe das 'mal 3 Stunden auf dem HP 802F KBC 05.22 Mainboard (HP
Z240) mit onboard Realtek-Soundkarte laufen lassen.

Bei mir war der größte Fehler dann 0,000180945239443%. Das sind 1.8 ppm.

Daraus folgere ich, dass die Frequenzangabe im Spektrum-Programm
SpecLab.exe bei einem Peak von 1 kHz 1.8 Milliherz ist. Das reicht für
mich zum Kalibrieren des 10 MHz TCXO im Radio auf 0.1 ppm (1 Hz) völlig aus.

An den ausgegebenen Prozentzahlen kann man nicht raten nach welcher
Methode der Fehler der Soundkarte gemessen wird.

Grüße Leo

Leo Baumann

unread,

Jul 14, 2022, 9:22:39 PM7/14/22

to

Am 14.07.2022 um 19:21 schrieb Michael Schwingen:

> Ich habe allerdings noch auf keinem Mobo und keiner Soundkarte etwas anderes
> als einen Standardquarz(-oszillator) gesehen. Wo da eine Genauigkeit besser
> als ein paar ppm (eher ein paar -10 ppm) herkommen soll, ist mir nicht klar.
>
> Ebensowenig ist mir klar, wie dieses Tool das messen will, ohne eine
> genauere Referenz heranzuziehen.

Hier ein paar Worte des Programmierers zu dem Programm SoundSpeed.exe:

https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

Da steht was von der Systemzeit, die während der Messung übers Internet
synchronisiert sein muss.

Ich habe das 'mal 3 Stunden auf dem HP 802F KBC 05.22 Mainboard (HP
Z240) mit onboard Realtek-Soundkarte laufen lassen.

Bei mir war der größte Fehler dann 0,000180945239443%. Das sind 1.8 ppm.

Daraus folgere ich, dass die Frequenzangabe im Spektrum-Programm

SpecLab.exe bei einem Peak von 1 kHz +-1.8 Milliherz ist. Das reicht für

Arno Welzel

unread,

Jul 15, 2022, 8:58:44 AM7/15/22

to

Leo Baumann:

Es wäre interessant zu wissen, wie das ermittelt wird.

Was wird denn als Referenz verwendet, um die Abweichung zu erkennen?

Arno Welzel

unread,

Jul 15, 2022, 9:03:56 AM7/15/22

to

Leo Baumann:

Danke für die Ergänzung.

"To confirm this theory I coded up a small application that uses the
Windows multimedia API test the clock speed of the sound card. It
compares this with the system clock to work out the error."

Leo Baumann

unread,

Jul 15, 2022, 9:09:19 AM7/15/22

to

Am 15.07.2022 um 14:58 schrieb Arno Welzel:
> Es wäre interessant zu wissen, wie das ermittelt wird.
>
> Was wird denn als Referenz verwendet, um die Abweichung zu erkennen?

Hier steht:

https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

Internet synchonisierte Computer-Systemzeit ...

:)

Leo Baumann

unread,

Jul 15, 2022, 9:17:30 AM7/15/22

to

Am 15.07.2022 um 14:58 schrieb Arno Welzel:

> Es wäre interessant zu wissen, wie das ermittelt wird.
>
> Was wird denn als Referenz verwendet, um die Abweichung zu erkennen?

Michael Schwingen

unread,

Jul 15, 2022, 1:10:27 PM7/15/22

to

On 2022-07-15, Leo Baumann <i...@leobaumann.de> wrote:
> https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php
>
> Da steht was von der Systemzeit, die während der Messung übers Internet
> synchronisiert sein muss.

Gut, OK - das mag funktionieren, fragt sich nur, *wie* genau das ist. Hat
ein normales Windows per Default NTP aktiv?

> Bei mir war der größte Fehler dann 0,000180945239443%. Das sind 1.8 ppm.
>
> Daraus folgere ich, dass die Frequenzangabe im Spektrum-Programm
> SpecLab.exe bei einem Peak von 1 kHz +-1.8 Milliherz ist. Das reicht für
> mich zum Kalibrieren des 10 MHz TCXO im Radio auf 0.1 ppm (1 Hz) völlig aus.

Wie willst Du mit einer Soundkarte, die 1.8ppm Fehler hat (Langzeit - der
Kurzzeitfehler kann deutlich größer sein!) etwas auf 0.1ppm genau
kalibrieren?

cu
Michael

Leo Baumann

unread,

Jul 15, 2022, 2:00:38 PM7/15/22

to

Am 15.07.2022 um 19:10 schrieb Michael Schwingen:
> Wie willst Du mit einer Soundkarte, die 1.8ppm Fehler hat (Langzeit - der
> Kurzzeitfehler kann deutlich größer sein!) etwas auf 0.1ppm genau
> kalibrieren?

Ich empfange auf 198 kHz den Normalfrequenzsender Droitwich, Betriebsart
CW, 1 kHz BFO, alles abgeleitet aus dem 10 MHz TCXO des Radios.

Die Spektrallinie speise ich in die Soundkarte des Computers ein und
beobachte die mit dem Spektrum-Programm SpecLab.exe. Nun die
Frequenzgenauigkeit des Peaks bei 1 KHz ist die Frequenzgenauigkeit der
Soundkarte, also +-1.8 Milliherz.

Eine Abweichung von 0.1 Hz im Spektralpeak bedeutet dann eine Abweichung
von 0.1 Hz des TCXO im Radio. Das sind 0.1 ppm.

:)

Leo Baumann

unread,

Jul 15, 2022, 2:07:00 PM7/15/22

to

Am 15.07.2022 um 20:00 schrieb Leo Baumann:
> Eine Abweichung von 0.1 Hz im Spektralpeak bedeutet dann eine Abweichung
> von 0.1 Hz des TCXO im Radio. Das sind 0.1 ppm.

Das funktioniert sogar bis 0.01 Hz Abweichung des TCXO, also 0.01 ppm.

BÄH!!!! :)

Leo Baumann

unread,

Jul 15, 2022, 2:31:21 PM7/15/22

to

Am 15.07.2022 um 19:10 schrieb Michael Schwingen:

> Wie willst Du mit einer Soundkarte, die 1.8ppm Fehler hat (Langzeit - der
> Kurzzeitfehler kann deutlich größer sein!) etwas auf 0.1ppm genau
> kalibrieren?

Ich empfange auf 198 kHz den Normalfrequenzsender Droitwich, Betriebsart
CW, 1 kHz BFO, alles abgeleitet aus dem 10 MHz TCXO des Radios.

Die Spektrallinie speise ich in die Soundkarte des Computers ein und
beobachte die mit dem Spektrum-Programm SpecLab.exe. Nun die
Frequenzgenauigkeit des Peaks bei 1 KHz ist die Frequenzgenauigkeit der
Soundkarte, also +-1.8 Milliherz.

Eine Abweichung von 0.1 Hz im Spektralpeak bedeutet dann eine Abweichung

von 0.1 Hz des TCXO im Radio. Das sind 0.01 ppm.

Rolf Bombach

unread,

Jul 15, 2022, 2:37:31 PM7/15/22

to

Arno Welzel schrieb:

Dies allein wäre ja Quark. Die sinnstiftende Ergänzung kommt ja noch:

"Remember that we are talking very small errors here so you will need
to leave the application running for a few hours at least, and keep your
system clock accurately synchronised at the start and end of the test."

--
mfg Rolf Bombach

Rolf Bombach

unread,

Jul 15, 2022, 2:49:04 PM7/15/22

to

Michael Schwingen schrieb:

> On 2022-07-14, Rolf Bombach <rolfnosp...@invalid.invalid> wrote:
>> Hmm, bei mir nicht einfach rauszukriegen. Jedenfalls gibt es vereinzelt
>> MoBos mit verstärktem Audio-Teil; ich hab keins, da das für meine Ohren
>> keinen Sinn ergibt.
>
> Ich habe allerdings noch auf keinem Mobo und keiner Soundkarte etwas anderes
> als einen Standardquarz(-oszillator) gesehen. Wo da eine Genauigkeit besser
> als ein paar ppm (eher ein paar -10 ppm) herkommen soll, ist mir nicht klar.

Sehe ich auch nicht. Die "enhanced" Audio-Teile sind offenbar einfach besser
vom System getrennt, haben bessere Kondensatoren (keine Kerkos) und Chips,
die z.B. DC-frei ("Kondensator-frei") am Ausgang sind und auch die doppelte
Ausgangsspannung deshalb aufweisen. ALC1220 oder so, Chips mit besserem
Rauschabstand usw. plus Schlangenöl. Manche Hersteller sind stolz auf
WIMA-Kondensatoren, warum auch immer.

> Ebensowenig ist mir klar, wie dieses Tool das messen will, ohne eine
> genauere Referenz heranzuziehen.

Ich glaube, dieses Tool hofft auf gute Sync der Systemclock aufs Internet.

--
mfg Rolf Bombach

Leo Baumann

unread,

Jul 15, 2022, 3:09:31 PM7/15/22

to

Am 15.07.2022 um 20:37 schrieb Rolf Bombach:
> Dies allein wäre ja Quark. Die sinnstiftende Ergänzung kommt ja noch:
>
> "Remember that we are talking very small errors here so you will need
> to leave the application running for a few hours at least, and keep your
> system clock accurately synchronised at the start and end of the test."

Ach wie gut dass niemand weiß, was Windows Systemzeit heißt!

Arno Welzel

unread,

Jul 15, 2022, 7:02:35 PM7/15/22

to

Michael Schwingen:

> On 2022-07-15, Leo Baumann <i...@leobaumann.de> wrote:
>> https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php
>>
>> Da steht was von der Systemzeit, die während der Messung übers Internet
>> synchronisiert sein muss.
>
> Gut, OK - das mag funktionieren, fragt sich nur, *wie* genau das ist. Hat
> ein normales Windows per Default NTP aktiv?

Ja.

Leo Baumann

unread,

Jul 15, 2022, 8:53:09 PM7/15/22

to

Am 16.07.2022 um 01:02 schrieb Arno Welzel:
>> Gut, OK - das mag funktionieren, fragt sich nur,*wie* genau das ist. Hat

>> ein normales Windows per Default NTP aktiv?
> Ja.

Es steht geschrieben, dass NTP die Systemzeit nach oben bis zu 10 ms
halten kann. Die Frage ist nur wie genau ist NTP nach unten?

Grüße

Leo Baumann

unread,

Jul 15, 2022, 9:02:33 PM7/15/22

to

Am 16.07.2022 um 02:53 schrieb Leo Baumann:
>>> Gut, OK - das mag funktionieren, fragt sich nur,*wie* genau das ist.
>>> Hat
>>> ein normales Windows per Default NTP aktiv?
>> Ja.
>
> Es steht geschrieben, dass NTP die Systemzeit nach oben bis zu 10 ms
> halten kann. Die Frage ist nur wie genau ist NTP nach unten?

Ist der Internet-Provider schon als lokales Netzwerk zu verstehen, dann
steht da 200 us ...

Gruß

Rupert Haselbeck

unread,

Jul 16, 2022, 2:50:10 AM7/16/22

to

Arno Welzel schrieb:
> Michael Schwingen:

>> Gut, OK - das mag funktionieren, fragt sich nur, *wie* genau das ist. Hat
>> ein normales Windows per Default NTP aktiv?
>
> Ja.

Und es fragt den Server allwöchentlich nach der aktuellen Zeit...

MfG
Rupert

Arno Welzel

unread,

Jul 16, 2022, 4:57:50 AM7/16/22

to

Leo Baumann:

Wieso "nach oben"?

NTP ermöglich eine Genauigkeit von 10 ms - das bedeutet die Zeit kann
sowohl nach unten wie oben um 10 ms abweichen.

In lokalen Netzen geht es auch genauer, wenn man da einen
Stratum-1-Server hat, der seine Zeit via GPS o.Ä. bekommt.

Arno Welzel

unread,

Jul 16, 2022, 4:58:51 AM7/16/22

to

Leo Baumann:

Ist er aber nicht. Mit "lokales Netzwerk" ist ein Stratum-1-Server
gemeint, den man direkt per LAN-Verbindung erreicht. Also eine Maschine,
die als NTP-Server dient und ihre Zeit direkt per GPS o.Ä. abgleicht.

Arno Welzel

unread,

Jul 16, 2022, 4:59:22 AM7/16/22

to

Rupert Haselbeck:

Und dazwischen weicht die Zeit ja nach Hardware auch gerne mal um einige
100ms ab - BTDT.

Leo Baumann

unread,

Jul 16, 2022, 5:01:08 AM7/16/22

to

Ich habe das so verstanden:

Wenn die Systemzeit bis zu 10 ms abweicht kann NTP das korrigieren.-
Die Genauigkeit in einem lokalen Netz (Internet Provider) ist 200 us
oder sogar besser.

Grüße

Leo Baumann

unread,

Jul 16, 2022, 5:03:25 AM7/16/22

to

Vielleicht hat ein Internet-Provider ja GPS-Startum-1 oder sowas???

Rupert Haselbeck

unread,

Jul 16, 2022, 5:20:10 AM7/16/22

to

Arno Welzel schrieb:

Ja, das kommt natürlich vor. Aber Zweiflern kann geholfen werden.
Auch unter Windows 10 ist der Defaultwert für "Special Poll Interval",
zu finden unter
"Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient"
noch immer "604800" Sekunden. Bei höheren Genauigkeitsanforderungen mag
es sich anbieten, diesen Wert zu ändern (und den Zeitservice neu zu
starten).

MfG
Rupert

Arno Welzel

unread,

Jul 16, 2022, 5:39:29 AM7/16/22

to

Den erreicht man aber nicht per LAN sondern nur über die Anbindung via
DSL, Kabel oder Glasfaser - und damit mit deutlichen
Laufzeitschwankungen der Pakete.

Arno Welzel

unread,

Jul 16, 2022, 5:39:55 AM7/16/22

to

Der Internet Provider ist aber nicht "lokales Netz".

Arno Welzel

unread,

Jul 16, 2022, 5:41:46 AM7/16/22

to

Rupert Haselbeck:

> Arno Welzel schrieb:
>> Rupert Haselbeck:
>>> Arno Welzel schrieb:
>>>> Michael Schwingen:
>>>>> Gut, OK - das mag funktionieren, fragt sich nur, *wie* genau das ist. Hat
>>>>> ein normales Windows per Default NTP aktiv?
>>>>
>>>> Ja.
>>>
>>> Und es fragt den Server allwöchentlich nach der aktuellen Zeit...
>>
>> Und dazwischen weicht die Zeit ja nach Hardware auch gerne mal um einige
>> 100ms ab - BTDT.
>
> Ja, das kommt natürlich vor. Aber Zweiflern kann geholfen werden.

Ich rede nicht von "Zweifel" sondern dass es so *ist*, weil die Hardware
bei weitem nicht so genau ist, wie man es gerne hätte und handesübliche
RTCs auch gerne mal ein paar Sekunden pro Monat driften. Das kann ich
sehr leicht feststellen, wenn ich die Zeit des PCs mit den Daten eines
DCF-77-Empfängers oder eine GPS-Empfängers vergleiche.

Genau deshalb gibt es ja Protokolle wie NTP.

> Auch unter Windows 10 ist der Defaultwert für "Special Poll Interval",
> zu finden unter
> "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient"
> noch immer "604800" Sekunden. Bei höheren Genauigkeitsanforderungen mag
> es sich anbieten, diesen Wert zu ändern (und den Zeitservice neu zu
> starten).

ACK.

Helmut Schellong

unread,

Jul 16, 2022, 6:28:35 AM7/16/22

to

Leo Baumann

unread,

Jul 16, 2022, 6:33:33 AM7/16/22

to

Am 16.07.2022 um 12:29 schrieb Helmut Schellong:
> Eine Exe kann auch per Protokoll NTP sich ganz unabhängig
> die Zeit von einem NTP-Server holen.

Ich habe das so verstanden, dass wenn der Rechner am Internet ist NTP
die Systemzeit stabilisiert. Die exe greift dann auf den Systemtimer zu.

Grüße

Leo Baumann

unread,

Jul 16, 2022, 6:35:31 AM7/16/22

to

Am 16.07.2022 um 12:29 schrieb Helmut Schellong:

> Eine Exe kann auch per Protokoll NTP sich ganz unabhängig
> die Zeit von einem NTP-Server holen.

Scheiß egal, Alistair wird das schon richtig gemacht haben - Hauptsache
SoundSpeed.exe funktioniert. - haha

Grüße

Helmut Schellong

unread,

Jul 16, 2022, 6:40:34 AM7/16/22

to

Der Takt in einem Betriebssystem beträgt 100 Hz, also 10ms Auflösung.
Eine höhere Genauigkeit gibt es nicht.
Eine andere Frequenz als 100 Hz (auf einem PC) ist mir jedenfalls nicht bekannt.

Und falls ein Objekt die Zeit in Nanosekunden hält, wird eben alle 10ms
der Wert 10.000.000 dort aufaddiert.

Arno Welzel

unread,

Jul 16, 2022, 7:11:26 AM7/16/22

to

Helmut Schellong:

> On 07/16/2022 11:00, Leo Baumann wrote:
>> Am 16.07.2022 um 10:57 schrieb Arno Welzel:
>>> Leo Baumann:
>>>
>>>> Am 16.07.2022 um 01:02 schrieb Arno Welzel:
>>>>>> Gut, OK - das mag funktionieren, fragt sich nur,*wie* genau das ist. Hat
>>>>>> ein normales Windows per Default NTP aktiv?
>>>>> Ja.
>>>>
>>>> Es steht geschrieben, dass NTP die Systemzeit nach oben bis zu 10 ms
>>>> halten kann. Die Frage ist nur wie genau ist NTP nach unten?
>>>
>>> Wieso "nach oben"?
>>>
>>> NTP ermöglich eine Genauigkeit von 10 ms - das bedeutet die Zeit kann
>>> sowohl nach unten wie oben um 10 ms abweichen.
>>>
>>> In lokalen Netzen geht es auch genauer, wenn man da einen
>>> Stratum-1-Server hat, der seine Zeit via GPS o.Ä. bekommt.
>>
>> Ich habe das so verstanden:
>>
>> Wenn die Systemzeit bis zu 10 ms abweicht kann NTP das korrigieren.-
>> Die Genauigkeit in einem lokalen Netz (Internet Provider) ist 200 us oder sogar besser.
>>
>>
>
> Der Takt in einem Betriebssystem beträgt 100 Hz, also 10ms Auflösung.
> Eine höhere Genauigkeit gibt es nicht.
> Eine andere Frequenz als 100 Hz (auf einem PC) ist mir jedenfalls nicht bekannt.

Dann hast Du offenbar noch nie von High Precision Event Timern gehört.
Aber die gibt es ja auch erst seit rund 22 Jahren:

<https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf>

Helmut Schellong

unread,

Jul 16, 2022, 8:11:41 AM7/16/22

to

Die Exe _kann_ auf den Systemtimer zugreifen, wenn das System eine Zeit unterhält.
Sie _muß_ das aber nicht, sondern kann sich die Zeit unabhängig besorgen.

Ungenauigkeiten dabei sind irrelevant, wenn es um lange Meßprozesse geht.
Also ich brauche die absolute Zeit _höchstens_ mit einer Genauigkeit von 1 s.
Ich habe meinen NTP-Dämon nicht gestartet, sondern rufe dann und wann
ntpdate -t 10 ptbtime1.ptb.de
16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
auf.

Für extrem hohe Auflösung verwende ich: uint64_t rdtsc(void);
http://www.schellong.de/htm/math87.htm#tsc
Dessen Auflösung beträgt bei mir ⅓ ns.

Für professionelle Messungen verwende ich Funktionen, die nur
bei aktivem Prozeß inkrementieren.
TSC hingegen läuft ununterbrochen durch; bei ruhendem System ist das aber okay.

Helmut Schellong

unread,

Jul 16, 2022, 8:17:59 AM7/16/22

to

Es geht darum, daß gefragt wurde, ob Windows per Default NTP gestartet hat...
Und das ist im Prinzip egal.

Ich hole mir die Zeit händisch per: ntpdate -t 10 ptbtime1.ptb.de
Und der NTP-Dämon ist bei mir _nicht_ gestartet.
Folglich brauche ich kein laufendes Zeitsystem.

Arno Welzel

unread,

Jul 16, 2022, 8:24:31 AM7/16/22

to

Helmut Schellong:

> On 07/16/2022 12:35, Leo Baumann wrote:
>> Am 16.07.2022 um 12:29 schrieb Helmut Schellong:
>>> Eine Exe kann auch per Protokoll NTP sich ganz unabhängig
>>> die Zeit von einem NTP-Server holen.
>>
>> Scheiß egal, Alistair wird das schon richtig gemacht haben - Hauptsache SoundSpeed.exe funktioniert. - haha
>>
>>
>
> Es geht darum, daß gefragt wurde, ob Windows per Default NTP gestartet hat...
> Und das ist im Prinzip egal.
>
> Ich hole mir die Zeit händisch per: ntpdate -t 10 ptbtime1.ptb.de
> Und der NTP-Dämon ist bei mir _nicht_ gestartet.
> Folglich brauche ich kein laufendes Zeitsystem.

Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
korrigiert auch die Drift der Systemzeit.

Helmut Schellong

unread,

Jul 16, 2022, 8:35:57 AM7/16/22

to

Du willst wohl wie üblich herumkacken.
Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
je umging, eine solche Zeitnahme nicht arbeitete!
Außerdem hat das wohl nichts mit _dem_ Zeit-Tick eines BS zu tun.

Natürlich habe ich auch schon vor Jahrzehnten von _vielen_ Zusätzen gelesen, die
für PCs erhältlich sind; es gibt viel Werbung in Fachzeitschriften...

Auf Mikrokontrollern, ja, da habe ich mir oft eine eigene genauere Zeitnahme gestrickt.
Beispielsweise 1 Tick pro ms in einem IRPT, Inkrement alle 64ms in einem 'long', etc.

Helmut Schellong

unread,

Jul 16, 2022, 8:42:54 AM7/16/22

to

Das weiß ich, aber mein Dämon läuft ja nicht...

ntpdate -t 10 ptbtime1.ptb.de
16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec

Das hatte ich bereits gepostet.
Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
Ist mir schnuppe!
Ich brauche genaue Zeitdauern!, keine ganz genaue (amtliche) Uhrzeit.

Stefan Wiens

unread,

Jul 16, 2022, 9:05:44 AM7/16/22

to

Siehe adjtimex(3) bzw. ntp_adjtime(3).

--
Stefan

Stefan Wiens

unread,

Jul 16, 2022, 9:08:44 AM7/16/22

to

Siehe adjtimex(2) bzw. ntp_adjtime(3).

--
Stefan

Arno Welzel

unread,

Jul 16, 2022, 12:23:17 PM7/16/22

to

Helmut Schellong:

> On 07/16/2022 14:24, Arno Welzel wrote:

[...]

>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>> korrigiert auch die Drift der Systemzeit.
>>
> Das weiß ich, aber mein Dämon läuft ja nicht...
>
> ntpdate -t 10 ptbtime1.ptb.de
> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
>
> Das hatte ich bereits gepostet.
> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.

Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.

> Ist mir schnuppe!

Das ist schön für Dich.

> Ich brauche genaue Zeitdauern!, keine ganz genaue (amtliche) Uhrzeit.

Darum ging es aber eben genau *nicht*.

Arno Welzel

unread,

Jul 16, 2022, 12:27:23 PM7/16/22

to

Helmut Schellong:

> On 07/16/2022 13:11, Arno Welzel wrote:
>> Helmut Schellong:

[...]

>>> Der Takt in einem Betriebssystem beträgt 100 Hz, also 10ms Auflösung.
>>> Eine höhere Genauigkeit gibt es nicht.
>>> Eine andere Frequenz als 100 Hz (auf einem PC) ist mir jedenfalls nicht bekannt.
>>
>> Dann hast Du offenbar noch nie von High Precision Event Timern gehört.
>> Aber die gibt es ja auch erst seit rund 22 Jahren:
>>
>> <https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf>
>>
> Du willst wohl wie üblich herumkacken.

Nein, nur deine Aussage richtigstellen, dass "ein Betriebssystem" nicht
Zeitabläuft nicht mit weniger als 10 ms auflösen kann.

> Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
> je umging, eine solche Zeitnahme nicht arbeitete!

Und genau das ist komplett irrelevant, was Du persönlich so gemacht
hast. Betriebssysteme nutzen selbstverständlich auch genauere Zeitnahmen
als nur 100 Hz, wenn nötig.

Helmut Schellong

unread,

Jul 16, 2022, 2:55:05 PM7/16/22

to

On 07/16/2022 18:23, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 07/16/2022 14:24, Arno Welzel wrote:
> [...]
>>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>>> korrigiert auch die Drift der Systemzeit.
>>>
>> Das weiß ich, aber mein Dämon läuft ja nicht...
>>
>> ntpdate -t 10 ptbtime1.ptb.de
>> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
>>
>> Das hatte ich bereits gepostet.
>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.

> Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.

Ich habe das Kommando seit etwa 3 Monaten nicht aufgerufen.
Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
Auch 150 s Abweichung wären egal gewesen.

>> Ist mir schnuppe!
>
> Das ist schön für Dich.

Nicht nur; welcher Privatmensch braucht denn die ganz genaue amtliche Uhrzeit?

>> Ich brauche genaue Zeitdauern!, keine ganz genaue (amtliche) Uhrzeit.
>
> Darum ging es aber eben genau *nicht*.
>
>

Doch.
Es ging um eine Soundkarte, die gar keine Uhrzeit anzeigt.
Sicher geht es da um Zeitdauern, nicht um absolute Werte.
Um die Differenzen zwischen jeweils zwei absoluten Werten.

Helmut Schellong

unread,

Jul 16, 2022, 3:13:03 PM7/16/22

to

On 07/16/2022 18:27, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 07/16/2022 13:11, Arno Welzel wrote:
>>> Helmut Schellong:
> [...]
>>>> Der Takt in einem Betriebssystem beträgt 100 Hz, also 10ms Auflösung.
>>>> Eine höhere Genauigkeit gibt es nicht.
>>>> Eine andere Frequenz als 100 Hz (auf einem PC) ist mir jedenfalls nicht bekannt.
>>>
>>> Dann hast Du offenbar noch nie von High Precision Event Timern gehört.
>>> Aber die gibt es ja auch erst seit rund 22 Jahren:
>>>
>>> <https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf>
>>>
>> Du willst wohl wie üblich herumkacken.
>
> Nein, nur deine Aussage richtigstellen, dass "ein Betriebssystem" nicht
> Zeitabläuft nicht mit weniger als 10 ms auflösen kann.

Kann es ja auch in aller aller Regel nicht!

>> Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
>> je umging, eine solche Zeitnahme nicht arbeitete!
>
> Und genau das ist komplett irrelevant, was Du persönlich so gemacht
> hast. Betriebssysteme nutzen selbstverständlich auch genauere Zeitnahmen
> als nur 100 Hz, wenn nötig.
>

Nenne mir einen solchen PC in Privathand konkret...

Von 100000 PCs vielleicht einer.
Und Du willst nun diese 10 ppm zu einem _erheblichen_, nicht vernachlässigbaren Anteil erklären?

|Scope:
|This specification provides register model and programming interface definitions for new event timer
|hardware for use on Intel Architecture-based Personal Computers. In this specification, the terms ‘IA-PC
|HPET and ‘Event Timers’ refer to the same timer hardware.
|The IA-PC HPET Specification defines timer hardware that is intended to initially supplement and
|eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic
|Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs.

Diese neue Hardware muß von einem BS unterstützt werden!
Synchronizing, Scheduling, Time Stamping:
Das erfordert große Änderungen im Kernel, bei Kommandos und in Libs, man-Pages, ...

Das meinte ich oben mit 'herumkacken'.

Thomas Einzel

unread,

Jul 16, 2022, 3:23:00 PM7/16/22

to

Am 16.07.2022 um 20:55 schrieb Helmut Schellong:
> On 07/16/2022 18:23, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 07/16/2022 14:24, Arno Welzel wrote:
>> [...]
>>>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>>>> korrigiert auch die Drift der Systemzeit.
>>>>
>>> Das weiß ich, aber mein Dämon läuft ja nicht...
>>>
>>> ntpdate -t 10 ptbtime1.ptb.de
>>> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset
>>> -28.158675 sec
>>>
>>> Das hatte ich bereits gepostet.
>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>
>> Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.
>
> Ich habe das Kommando seit etwa 3 Monaten nicht aufgerufen.
> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
> Auch 150 s Abweichung wären egal gewesen.

Mit https://uhr.ptb.de/ auf (Δt klicken) schnell zu sehen.
...

> Nicht nur; welcher Privatmensch braucht denn die ganz genaue amtliche
> Uhrzeit?

Ich habe es gern auf <2s genau, besser <0,5s. Im LAN synce ich meinen
ntp Server mit den ntp Servern der PTP, also Stratum 2. Seit vielen
Jahren und damals korrekt angemeldet.

Mit den 10^−7 Genauigkeiten im Thread hat das natürlich nichts zu tun,
das brauche ich privat nicht.
BTW - das man 10^−7 mit eine Soundkarte und einer
Langzeitsynchronisation erreichen kann glaube ich gern, wenn ich einen
Vergleich mit einem geeichten Frequenznormal (eine Genauigkeitsklaase
besser) gesehen habe.
--
Thomas

Sieghard Schicktanz

unread,

Jul 16, 2022, 4:13:06 PM7/16/22

to

Hallo Rolf Bombach,

Du schriebst am Fri, 15 Jul 2022 20:37:30 +0200:

> >> https://blog.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php
> >
> > Danke für die Ergänzung.
> >
> > "To confirm this theory I coded up a small application that uses the
> > Windows multimedia API test the clock speed of the sound card. It
> > compares this with the system clock to work out the error."
>
> Dies allein wäre ja Quark. Die sinnstiftende Ergänzung kommt ja noch:
>
> "Remember that we are talking very small errors here so you will need
> to leave the application running for a few hours at least, and keep
> your system clock accurately synchronised at the start and end of the
> test."

D.h. wenn ich einen Wobbelgenerator mit dem Ding so messe, daß jeder
Meßpunkt genau am Ende einer Wobbelperiode liegt, dann zeigt die
Messung auch, daß der eine Abweichung von 0,...ppm hat. egal wie groß
der eingestellte Wobbelfrequenzbereich ist?
(Und wenn die Mittenfrequenz konstant bleibt, aber die "Auslenkung" im
Lauf der Messung immer wieder verstellt wird, ändert das auch nix am
Ergebnis...)

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

Helmut Schellong

unread,

Jul 16, 2022, 5:15:01 PM7/16/22

to

On 07/16/2022 21:22, Thomas Einzel wrote:
> Am 16.07.2022 um 20:55 schrieb Helmut Schellong:
>> On 07/16/2022 18:23, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>>> On 07/16/2022 14:24, Arno Welzel wrote:
>>> [...]
>>>>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>>>>> korrigiert auch die Drift der Systemzeit.
>>>>>
>>>> Das weiß ich, aber mein Dämon läuft ja nicht...
>>>>
>>>> ntpdate -t 10 ptbtime1.ptb.de
>>>> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
>>>>
>>>> Das hatte ich bereits gepostet.
>>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>>
>>> Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.
>>
>> Ich habe das Kommando seit etwa 3 Monaten nicht aufgerufen.
>> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
>> Auch 150 s Abweichung wären egal gewesen.
>
> Mit https://uhr.ptb.de/ auf (Δt klicken) schnell zu sehen.

Lokal bin ich aktuell 0,6 s voraus.

>> Nicht nur; welcher Privatmensch braucht denn die ganz genaue amtliche Uhrzeit?
>
> Ich habe es gern auf <2s genau, besser <0,5s. Im LAN synce ich meinen ntp Server mit den ntp Servern der PTP, also Stratum 2. Seit vielen Jahren und damals korrekt angemeldet.

Ich hatte das gemacht, als T-Online.de noch ntp-Server zugänglich hatte.
Das erhalten aber seit langer Zeit nur noch gewerbliche Kunden, sowie die
TO-Newsgroups auch wegfielen.

> Mit den 10^−7 Genauigkeiten im Thread hat das natürlich nichts zu tun, das brauche ich privat nicht.
> BTW - das man 10^−7 mit eine Soundkarte und einer Langzeitsynchronisation erreichen kann glaube ich gern, wenn ich einen Vergleich mit einem geeichten Frequenznormal (eine Genauigkeitsklaase besser) gesehen habe.

Das ist ähnlich mit den Schaltsekunden.
Da gibt es eine, wenn der Versatz >0,9 s erreicht hat.

Michael Schwingen

unread,

Jul 16, 2022, 6:15:34 PM7/16/22

to

On 2022-07-16, Helmut Schellong <r...@schellong.biz> wrote:
>> Nein, nur deine Aussage richtigstellen, dass "ein Betriebssystem" nicht
>> Zeitabläuft nicht mit weniger als 10 ms auflösen kann.
>
> Kann es ja auch in aller aller Regel nicht!

Doch. Die 100Hz-Timerinterrupts sind nicht die einzigen Interrupts.

>>> Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
>>> je umging, eine solche Zeitnahme nicht arbeitete!
>>
>> Und genau das ist komplett irrelevant, was Du persönlich so gemacht
>> hast. Betriebssysteme nutzen selbstverständlich auch genauere Zeitnahmen
>> als nur 100 Hz, wenn nötig.
>>
>
> Nenne mir einen solchen PC in Privathand konkret...

Hier. CONFIG_HZ_300=y, allerdings in Kombination mit CONFIG_NO_HZ_FULL, also
überhaupt keine festen Timerinterrupts.

> Und Du willst nun diese 10 ppm zu einem _erheblichen_, nicht vernachlässigbaren Anteil erklären?
>
>|Scope:
>|This specification provides register model and programming interface definitions for new event timer
>|hardware for use on Intel Architecture-based Personal Computers. In this specification, the terms ‘IA-PC
>|HPET and ‘Event Timers’ refer to the same timer hardware.
>|The IA-PC HPET Specification defines timer hardware that is intended to initially supplement and
>|eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic
>|Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs.
>
> Diese neue Hardware muß von einem BS unterstützt werden!

Diese neue Hardware ist seit vielen Jahren (seit 2005) Standard. Alles, was
neuer als Windows XP ist, sollte HPET benutzen.

cu
Michael

Michael Schwingen

unread,

Jul 16, 2022, 6:20:56 PM7/16/22

to

On 2022-07-16, Rupert Haselbeck <mein-re...@gmx.de> wrote:
> Und es fragt den Server allwöchentlich nach der aktuellen Zeit...

Und korrigiert die Kernel-Clock-Geschwindigkeit nicht (wie ein ntpd das mit
adjtimex tun würde)? Das klingt jetzt nicht so toll ...

Dann hat man zwar eine halbwegs richtige Zeit, aber einmal die Woche
Sprünge, und die Genauigkeit der Timer ist immer noch so wie der Quarz auf
dem Mainboard und nicht NTP-genau.

cu
Michael

Helmut Schellong

unread,

Jul 17, 2022, 4:59:27 AM7/17/22

to

On 07/17/2022 00:15, Michael Schwingen wrote:
> On 2022-07-16, Helmut Schellong <r...@schellong.biz> wrote:
>>> Nein, nur deine Aussage richtigstellen, dass "ein Betriebssystem" nicht
>>> Zeitabläuft nicht mit weniger als 10 ms auflösen kann.
>>
>> Kann es ja auch in aller aller Regel nicht!
>
> Doch. Die 100Hz-Timerinterrupts sind nicht die einzigen Interrupts.

Und die anderen Interrupts sind wohl keine Timer-Interrupts.

>>>> Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
>>>> je umging, eine solche Zeitnahme nicht arbeitete!
>>>
>>> Und genau das ist komplett irrelevant, was Du persönlich so gemacht
>>> hast. Betriebssysteme nutzen selbstverständlich auch genauere Zeitnahmen
>>> als nur 100 Hz, wenn nötig.
>>>
>>
>> Nenne mir einen solchen PC in Privathand konkret...
>
> Hier. CONFIG_HZ_300=y, allerdings in Kombination mit CONFIG_NO_HZ_FULL, also
> überhaupt keine festen Timerinterrupts.

Daß ich die 100 Hz verändern kann, weiß ich, seit meinen SCO-Betriebssystemen.
Es wird aber empfohlen, die 100 Hz stehen zu lassen.

>> Und Du willst nun diese 10 ppm zu einem _erheblichen_, nicht vernachlässigbaren Anteil erklären?
>>
>> |Scope:
>> |This specification provides register model and programming interface definitions for new event timer
>> |hardware for use on Intel Architecture-based Personal Computers. In this specification, the terms ‘IA-PC
>> |HPET and ‘Event Timers’ refer to the same timer hardware.
>> |The IA-PC HPET Specification defines timer hardware that is intended to initially supplement and
>> |eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic
>> |Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs.
>>
>> Diese neue Hardware muß von einem BS unterstützt werden!
>
> Diese neue Hardware ist seit vielen Jahren (seit 2005) Standard. Alles, was
> neuer als Windows XP ist, sollte HPET benutzen.
>
>

Ja, das gibt es (aktuell):

Event timer "LAPIC" quality 100
Event timer "RTC" frequency 32768 Hz quality 0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0

kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.HPET.counter: 3013495652
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.quality: 950

Unter meinem FreeBSD haben die Zeitdauer-Funktionen aus den Libs
eine Auflösung von 10 ms.
Die Uhrzeit kann ich mir auch mit scheinbar höherer Auflösung liefern lassen;
aber die reale Auflösung ist 10 ms.

Was nützt HPET mir, wenn es offenbar keine geeignete Zeitnahme-Funktion gibt, die auf HPET aufsetzt?
Es geht zudem in einem gewissen Maß um Portabilität.
Die üblichen Funktionen (z.B. <time.h>) basieren offenbar nicht auf HPET.
Hätte man aber machen können...

Eine explizite Analyse habe ich aber schon lange nicht mehr gemacht.
Ich verwende u.a. setitimer() und getitimer(), die aber keine C-Funktionen sind.

Michael Schwingen

unread,

Jul 17, 2022, 7:34:04 AM7/17/22

to

On 2022-07-17, Helmut Schellong <r...@schellong.biz> wrote:
>> Doch. Die 100Hz-Timerinterrupts sind nicht die einzigen Interrupts.
>
> Und die anderen Interrupts sind wohl keine Timer-Interrupts.

Klar gibt es andere Interrupts. Was wichtiger ist: es gibt Timer-Interrupts
mit <10ms Auflösung.

>> Hier. CONFIG_HZ_300=y, allerdings in Kombination mit CONFIG_NO_HZ_FULL, also
>> überhaupt keine festen Timerinterrupts.
>
> Daß ich die 100 Hz verändern kann, weiß ich, seit meinen SCO-Betriebssystemen.
> Es wird aber empfohlen, die 100 Hz stehen zu lassen.

Es hiess mal vor einiger Zeit, 300HZ sei für Desktop-Systeme optimal, weil
das mit 50Hz- und 60Hz-Videowiedergabe passt. Seit HRTimer verfügbar sind,
dürfte das obsolet sein, und bei einem tickless-kernel eh.

> Was nützt HPET mir, wenn es offenbar keine geeignete Zeitnahme-Funktion gibt, die auf HPET aufsetzt?
> Es geht zudem in einem gewissen Maß um Portabilität.
> Die üblichen Funktionen (z.B. <time.h>) basieren offenbar nicht auf HPET.
> Hätte man aber machen können...

https://docs.kernel.org/timers/highres.html

clock_gettime() kann Nanosekunden-Auflösung und ist anscheinend POSIX,
nanosleep() dito. Welche Timer mit welcher realen Auflösung verfügbar sind,
ist systemabhängig, aber besser als 10ms geht auf jeden Fall. time(7) meint:

Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally config‐
urable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of
sleep and timer system calls is no longer constrained by the jiffy, but instead can be
as accurate as the hardware allows (microsecond accuracy is typical of modern hard‐
ware). You can determine whether high-resolution timers are supported by checking the
resolution returned by a call to clock_getres(2) or looking at the "resolution" entries
in /proc/timer_list.

> Ich verwende u.a. setitimer() und getitimer(), die aber keine C-Funktionen sind.

Hä? Inwiefern keine C-Funktionen, setitimer(2) meint, die sind in
sys/time.h.

Posix meint "deprecated", man soll timer_gettime() verwenden, das
ist in time.h.

Ich gehe jetzt einfach mal davon aus, daß das unter Windows ähnlich
aussieht, Intel baut diese Features ja nicht zum Spass und extra nur für die
Linux-user ein.

cu
Michael

Arno Welzel

unread,

Jul 17, 2022, 7:38:00 AM7/17/22

to

Helmut Schellong:

> On 07/16/2022 18:27, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 07/16/2022 13:11, Arno Welzel wrote:
>>>> Helmut Schellong:
>> [...]
>>>>> Der Takt in einem Betriebssystem beträgt 100 Hz, also 10ms Auflösung.
>>>>> Eine höhere Genauigkeit gibt es nicht.
>>>>> Eine andere Frequenz als 100 Hz (auf einem PC) ist mir jedenfalls nicht bekannt.
>>>>
>>>> Dann hast Du offenbar noch nie von High Precision Event Timern gehört.
>>>> Aber die gibt es ja auch erst seit rund 22 Jahren:
>>>>
>>>> <https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf>
>>>>
>>> Du willst wohl wie üblich herumkacken.
>>
>> Nein, nur deine Aussage richtigstellen, dass "ein Betriebssystem" nicht
>> Zeitabläuft nicht mit weniger als 10 ms auflösen kann.
>
> Kann es ja auch in aller aller Regel nicht!

Mit HPET schon.

>>> Das ändert überhaupt nichts daran, daß in _allen_ PCs, mit denen ich
>>> je umging, eine solche Zeitnahme nicht arbeitete!
>>
>> Und genau das ist komplett irrelevant, was Du persönlich so gemacht
>> hast. Betriebssysteme nutzen selbstverständlich auch genauere Zeitnahmen
>> als nur 100 Hz, wenn nötig.
>>
>
> Nenne mir einen solchen PC in Privathand konkret...

So ziemlich jeder aus dem letzten 20 Jahren.

[...]

> |Scope:
> |This specification provides register model and programming interface definitions for new event timer
> |hardware for use on Intel Architecture-based Personal Computers. In this specification, the terms ‘IA-PC
> |HPET and ‘Event Timers’ refer to the same timer hardware.
> |The IA-PC HPET Specification defines timer hardware that is intended to initially supplement and
> |eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic
> |Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs.
>
> Diese neue Hardware muß von einem BS unterstützt werden!

Wird sie ja.

> Synchronizing, Scheduling, Time Stamping:
> Das erfordert große Änderungen im Kernel, bei Kommandos und in Libs, man-Pages, ...
>
> Das meinte ich oben mit 'herumkacken'.

Das gebe ich gerne zurück.

Arno Welzel

unread,

Jul 17, 2022, 7:47:15 AM7/17/22

to

Helmut Schellong:

> On 07/17/2022 00:15, Michael Schwingen wrote:
>> On 2022-07-16, Helmut Schellong <r...@schellong.biz> wrote:

[...]

>>> Nenne mir einen solchen PC in Privathand konkret...
>>
>> Hier. CONFIG_HZ_300=y, allerdings in Kombination mit CONFIG_NO_HZ_FULL, also
>> überhaupt keine festen Timerinterrupts.
>
> Daß ich die 100 Hz verändern kann, weiß ich, seit meinen SCO-Betriebssystemen.

Warum behauptest Du dann, dass mehr als 100 Hz nicht mögloch wären?

> Es wird aber empfohlen, die 100 Hz stehen zu lassen.

Was empfohlen wird, war aber nicht das Thema, sondern was praktisch
möglich ist.

[...]

>>> Diese neue Hardware muß von einem BS unterstützt werden!
>>
>> Diese neue Hardware ist seit vielen Jahren (seit 2005) Standard. Alles, was
>> neuer als Windows XP ist, sollte HPET benutzen.
>>
>>
>
> Ja, das gibt es (aktuell):
>
> Event timer "LAPIC" quality 100
> Event timer "RTC" frequency 32768 Hz quality 0
> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 950
> Event timer "HPET" frequency 14318180 Hz quality 450
> Event timer "HPET1" frequency 14318180 Hz quality 440
> Event timer "HPET2" frequency 14318180 Hz quality 440
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
>
> kern.timecounter.tc.i8254.frequency: 1193182
> kern.timecounter.tc.i8254.quality: 0
> kern.timecounter.tc.HPET.mask: 4294967295
> kern.timecounter.tc.HPET.counter: 3013495652
> kern.timecounter.tc.HPET.frequency: 14318180
> kern.timecounter.tc.HPET.quality: 950
>
> Unter meinem FreeBSD haben die Zeitdauer-Funktionen aus den Libs
> eine Auflösung von 10 ms.
> Die Uhrzeit kann ich mir auch mit scheinbar höherer Auflösung liefern lassen;
> aber die reale Auflösung ist 10 ms.
>
> Was nützt HPET mir, wenn es offenbar keine geeignete Zeitnahme-Funktion gibt, die auf HPET aufsetzt?

Gibt es.

<https://docs.kernel.org/timers/hrtimers.html>

<https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps>

> Es geht zudem in einem gewissen Maß um Portabilität.
> Die üblichen Funktionen (z.B. <time.h>) basieren offenbar nicht auf HPET.
> Hätte man aber machen können...

Ja und?

Nur weil etwas das in der von Dir bevorzugten Form nicht gibt, deswegen
existiert es für Dich generell nicht?

Arno Welzel

unread,

Jul 17, 2022, 7:59:41 AM7/17/22

to

Helmut Schellong:

> On 07/16/2022 18:23, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 07/16/2022 14:24, Arno Welzel wrote:
>> [...]
>>>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>>>> korrigiert auch die Drift der Systemzeit.
>>>>
>>> Das weiß ich, aber mein Dämon läuft ja nicht...
>>>
>>> ntpdate -t 10 ptbtime1.ptb.de
>>> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
>>>
>>> Das hatte ich bereits gepostet.
>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>
>> Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.
>
> Ich habe das Kommando seit etwa 3 Monaten nicht aufgerufen.

Also weicht die Uhr dann wohl pro Monat um etwa 9 Sekunden ab, was sich
nach drei Monaten auf 28 Sekunden summiert.

> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
> Auch 150 s Abweichung wären egal gewesen.

Ja, hast du schon gesagt. War dennoch nicht das Thema.

[...]

>> Darum ging es aber eben genau *nicht*.
>>
>>
> Doch.
> Es ging um eine Soundkarte, die gar keine Uhrzeit anzeigt.

Nein, aber es ging darum, das von einer Soundkarte wiedergegebene Signal
anhand der Systemzeit zu bewerten.

Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
gemessen wird, welche Frequenz real erreicht wird, wenn man eine
Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
definierte Zeitspanne misst.

> Sicher geht es da um Zeitdauern, nicht um absolute Werte.

Auch bei Zeitdauern ist es relevant, ob die Dauer exakt messbar ist oder
nicht.

> Um die Differenzen zwischen jeweils zwei absoluten Werten.

Korrekt. Und diese Differenz sollte halt möglichst genau sein, wenn
anhand der Dauer etwas beurteilen will.

Mag sein, dass in einem PC üblichen Schwankungen der Uhrzeit auch ohne
Korrektur der Drift keine Rolle für solche Messungen spielen, weil die
Messung ohnehin nur sehr kurz ist und es dann u.U. nur um Abweichungen
im Bereich von wenigen Millisekunden bei der gemessenen Dauer geht.
Dennoch führt NTP nicht nur eine einmalige Korrektur der Zeit durch
sondern kann auch dafür sorgen, dass die laufende Drift der lokalen
Systemzeit korrigiert wird, damit auch zwischend den Synchronisierungen
die Abweichung so gering wie möglich ist. Dass Du persönlich das nicht
brauchst, ist komplett irrelevant.

Arno Welzel

unread,

Jul 17, 2022, 8:03:55 AM7/17/22

to

Michael Schwingen:

> On 2022-07-16, Rupert Haselbeck <mein-re...@gmx.de> wrote:
>> Und es fragt den Server allwöchentlich nach der aktuellen Zeit...
>
> Und korrigiert die Kernel-Clock-Geschwindigkeit nicht (wie ein ntpd das mit
> adjtimex tun würde)? Das klingt jetzt nicht so toll ...

Der entsprechende Service bei Windows korrigiert die Zeit ähnlich wie NTP.

Siehe auch:

<https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-setsystemtimeadjustment>

Michael Schwingen

unread,

Jul 17, 2022, 12:55:04 PM7/17/22

to

On 2022-07-17, Arno Welzel <use...@arnowelzel.de> wrote:
>
> Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
> gemessen wird, welche Frequenz real erreicht wird, wenn man eine
> Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
> der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
> definierte Zeitspanne misst.

Das bräuchte wieder eine externe Referenz oder Messung des 1kHz-Signals.

Ich gehe davon aus, daß das Tool einfach Samples ausgibt und über eine
bekannte Zeit misst, wieviele Samples es waren. Das Timing gibt die
Soundkarte mit ihrem internen Takt vor, und am Ende kommen halt z.B. 48000
Samples/s * Testzeit heraus. Die Differenz von 48000 zu den gemessenen
Samples/s ist die Abweichung des Soundkarten-Taktes - vorausgesetzt, die
PC-Uhr ist exakt.

cu
Michael

Michael Schwingen

unread,

Jul 17, 2022, 12:56:27 PM7/17/22

to

On 2022-07-17, Arno Welzel <use...@arnowelzel.de> wrote:

>> Und korrigiert die Kernel-Clock-Geschwindigkeit nicht (wie ein ntpd das mit
>> adjtimex tun würde)? Das klingt jetzt nicht so toll ...
>
> Der entsprechende Service bei Windows korrigiert die Zeit ähnlich wie NTP.

Danke, dann ist das ja tatsächlich brauchbar.

cu
Michael

Helmut Schellong

unread,

Jul 17, 2022, 2:50:49 PM7/17/22

to

Keine C-Standard-Funktionen meine ich.

> Posix meint "deprecated", man soll timer_gettime() verwenden, das
> ist in time.h.

Ich bin momentan nicht sicher, ob dieser Timer getitimer() direkt ersetzen kann.

> Ich gehe jetzt einfach mal davon aus, daß das unter Windows ähnlich
> aussieht, Intel baut diese Features ja nicht zum Spass und extra nur für die
> Linux-user ein.
>
>

NAME
getitimer, setitimer - get/set value of interval timer

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <sys/time.h>
...
Time values smaller than the resolution of the system clock are rounded
up to this resolution (typically 10 milliseconds).

Von Letzterem rede ich die ganze Zeit.
Das begegnet mir sehr häufig.

FreeBSD schränkt die Funktionen nicht ein, hinsichtlich deprecated|obsolet.

Helmut Schellong

unread,

Jul 17, 2022, 3:04:23 PM7/17/22

to

On 07/17/2022 13:59, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 07/16/2022 18:23, Arno Welzel wrote:
>>> Helmut Schellong:
>>>
>>>> On 07/16/2022 14:24, Arno Welzel wrote:
>>> [...]
>>>>> Der NTP-Daemon macht aber mehr, als nur ab und zu die Zeit abfragen. Er
>>>>> korrigiert auch die Drift der Systemzeit.
>>>>>
>>>> Das weiß ich, aber mein Dämon läuft ja nicht...
>>>>
>>>> ntpdate -t 10 ptbtime1.ptb.de
>>>> 16 Jul 14:07:40 ntpdate[1511]: step time server 192.53.103.108 offset -28.158675 sec
>>>>
>>>> Das hatte ich bereits gepostet.
>>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>>
>>> Eben. Solche Sprünge bedeuten, dass die Uhr generell nicht genau läuft.
>>
>> Ich habe das Kommando seit etwa 3 Monaten nicht aufgerufen.
>
> Also weicht die Uhr dann wohl pro Monat um etwa 9 Sekunden ab, was sich
> nach drei Monaten auf 28 Sekunden summiert.

Nein, die Zeit kann in einem Tag z.B. 2,8 s abweichen. Hatte ich gerade.
Über mehrere Monate gibt es ein Auf und Ab.

>> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
>> Auch 150 s Abweichung wären egal gewesen.
>
> Ja, hast du schon gesagt. War dennoch nicht das Thema.

Das mit den 150 s hatte ich wohl nur einmal geschrieben.

> [...]
>>> Darum ging es aber eben genau *nicht*.
>>>
>>>
>> Doch.
>> Es ging um eine Soundkarte, die gar keine Uhrzeit anzeigt.
>
> Nein, aber es ging darum, das von einer Soundkarte wiedergegebene Signal
> anhand der Systemzeit zu bewerten.
>
> Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
> gemessen wird, welche Frequenz real erreicht wird, wenn man eine
> Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
> der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
> definierte Zeitspanne misst.
>
>> Sicher geht es da um Zeitdauern, nicht um absolute Werte.
>
> Auch bei Zeitdauern ist es relevant, ob die Dauer exakt messbar ist oder
> nicht.

Der entscheidende Unterschied ist, daß die absolute Zeit beliebig daneben liegen darf.
Hauptsache, der Wert inkrementiert linear.

Arno Welzel

unread,

Jul 17, 2022, 4:17:33 PM7/17/22

to

Michael Schwingen:

> On 2022-07-17, Arno Welzel <use...@arnowelzel.de> wrote:
>>
>> Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
>> gemessen wird, welche Frequenz real erreicht wird, wenn man eine
>> Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
>> der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
>> definierte Zeitspanne misst.
>
> Das bräuchte wieder eine externe Referenz oder Messung des 1kHz-Signals.

Habe ich ja geschrieben: die externe Referenz ist die Systemzeit und die
Messung vermittelt, wieviele Samples in der gegebenen Zeit abgespielt
wurden.

> Ich gehe davon aus, daß das Tool einfach Samples ausgibt und über eine
> bekannte Zeit misst, wieviele Samples es waren. Das Timing gibt die

Was genau das ist, was ich geschrieben habe, nur anders ausgedrückt.

> Soundkarte mit ihrem internen Takt vor, und am Ende kommen halt z.B. 48000
> Samples/s * Testzeit heraus. Die Differenz von 48000 zu den gemessenen
> Samples/s ist die Abweichung des Soundkarten-Taktes - vorausgesetzt, die
> PC-Uhr ist exakt.

Eben.

Leo Baumann

unread,

Jul 17, 2022, 4:19:48 PM7/17/22

to

Na, dann haben wir es doch - SoundSpeed.exe funktioniert :)

Grüße

Arno Welzel

unread,

Jul 17, 2022, 4:21:47 PM7/17/22

to

Helmut Schellong:

> On 07/17/2022 13:59, Arno Welzel wrote:
>> Helmut Schellong:

[...]

>>> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
>>> Auch 150 s Abweichung wären egal gewesen.
>>
>> Ja, hast du schon gesagt. War dennoch nicht das Thema.
>
> Das mit den 150 s hatte ich wohl nur einmal geschrieben.

Nein, dass Dir größere Abweichungen und deren schlagartige Korrektur
beim NTP-Sync egal sind, das hast Du mehr als einmal geschrieben.

[...]

>> Auch bei Zeitdauern ist es relevant, ob die Dauer exakt messbar ist oder
>> nicht.
> Der entscheidende Unterschied ist, daß die absolute Zeit beliebig daneben liegen darf.

Wenn die Systemuhr schneller oder langsamer als vorgesehen läuft, hat
man eben aber keine exakte Dauer, sondern einen Fehler. Wenn als Dauer
aufgrund der Zeitangabe z.B. 100 Sekunden ermittelt wurden, können das
auch 100,2 oder 99,75 Sekunden sein - erst recht, wenn die Systemzeit
keine Drift-Korrektur durch NTP oder vergleichbare Dienste hat.

Helmut Schellong

unread,

Jul 17, 2022, 5:09:13 PM7/17/22

to

On 07/17/2022 22:21, Arno Welzel wrote:
> Helmut Schellong:
>
>> On 07/17/2022 13:59, Arno Welzel wrote:
>>> Helmut Schellong:
> [...]
>>>> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
>>>> Auch 150 s Abweichung wären egal gewesen.
>>>
>>> Ja, hast du schon gesagt. War dennoch nicht das Thema.
>>
>> Das mit den 150 s hatte ich wohl nur einmal geschrieben.
>
> Nein, dass Dir größere Abweichungen und deren schlagartige Korrektur
> beim NTP-Sync egal sind, das hast Du mehr als einmal geschrieben.

Und ich hatte dabei schon selbst geschrieben, daß ich das
bereits geschrieben hatte.

Das mit den 150 s hatte ich NUR in 07/16/2022 20:55 geschrieben.
Also 1-mal, wie ich stark vermutete.

> [...]
>>> Auch bei Zeitdauern ist es relevant, ob die Dauer exakt messbar ist oder
>>> nicht.
>> Der entscheidende Unterschied ist, daß die absolute Zeit beliebig daneben liegen darf.
>
> Wenn die Systemuhr schneller oder langsamer als vorgesehen läuft, hat
> man eben aber keine exakte Dauer, sondern einen Fehler. Wenn als Dauer
> aufgrund der Zeitangabe z.B. 100 Sekunden ermittelt wurden, können das
> auch 100,2 oder 99,75 Sekunden sein - erst recht, wenn die Systemzeit
> keine Drift-Korrektur durch NTP oder vergleichbare Dienste hat.
>
>

Ich schrieb, daß die Zeit linear inkrementieren muß - in der Hauptsache.
Das fehlt ja hier.
Alle Dauern sind dann als Ticks (Einheit [1]) genau.
Skalieren kann man dann später mit einem Faktor.

Michael Schwingen

unread,

Jul 18, 2022, 2:01:05 PM7/18/22

to

On 2022-07-17, Arno Welzel <use...@arnowelzel.de> wrote:
>>>
>>> Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
>>> gemessen wird, welche Frequenz real erreicht wird, wenn man eine
>>> Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
>>> der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
>>> definierte Zeitspanne misst.
>>
>> Das bräuchte wieder eine externe Referenz oder Messung des 1kHz-Signals.
>
> Habe ich ja geschrieben: die externe Referenz ist die Systemzeit und die
> Messung vermittelt, wieviele Samples in der gegebenen Zeit abgespielt
> wurden.

Ich hatte Dich so verstanden, daß Du die Frequenz des 1kHz-Signals
messen/prüfen willst.

Wenn man Samples zählt, ist es egal, was für ein Signal die Soundkarte
ausgibt.

cu
Michael

Marc Haber

unread,

Jul 18, 2022, 3:10:37 PM7/18/22

to

Helmut Schellong <r...@schellong.biz> wrote:
>Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.

>Ist mir schnuppe!

Aber die Server der PTB benutzen anstelle eines Poolservers.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Helmut Schellong

unread,

Jul 18, 2022, 3:27:10 PM7/18/22

to

On 07/18/2022 21:10, Marc Haber wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>> Ist mir schnuppe!
>
> Aber die Server der PTB benutzen anstelle eines Poolservers.
>

ptbtime ist ein Kommando, das ich vielleicht einmal pro Monat aufrufe.
Das ist vollkommen vernachlässigbar.

Bernd Laengerich

unread,

Jul 19, 2022, 2:27:40 AM7/19/22

to

Am 18.07.2022 um 20:01 schrieb Michael Schwingen:

> Wenn man Samples zählt, ist es egal, was für ein Signal die Soundkarte
> ausgibt.

Es gibt gar keines aus. Ich vermute es sampelt einen Eingang und zählt dort.
Jedenfalls läuft es auch wenn man etwas anderes abspielt.

Bernd

Michael Schwingen

unread,

Jul 19, 2022, 12:16:30 PM7/19/22

to

On 2022-07-19, Bernd Laengerich <Bernd.La...@web.de> wrote:
> Es gibt gar keines aus. Ich vermute es sampelt einen Eingang und zählt dort.
> Jedenfalls läuft es auch wenn man etwas anderes abspielt.

Gut, das geht natürlich für beide Richtungen. Wenn die Soundkarte für
Aufnahme und Wiedergabe einen gemeinsamen Takt verwendet (was
wahrscheinlich, aber nicht zwingend ist), ist das Ergebnis äquivalent.

cu
Michael

Arno Welzel

unread,

Jul 20, 2022, 8:29:56 AM7/20/22

to

Michael Schwingen:

> On 2022-07-17, Arno Welzel <use...@arnowelzel.de> wrote:
>>>>
>>>> Ich kenne den Code von "SoundSpeed" nicht - aber denkbar wäre, dass z.B.
>>>> gemessen wird, welche Frequenz real erreicht wird, wenn man eine
>>>> Wellenform für 1 kHz in den DAC gibt und dann prüft, welche Frequenz bei
>>>> der Rückwandelung des analogen Ausgangs herauskommt, wenn man für eine
>>>> definierte Zeitspanne misst.
>>>
>>> Das bräuchte wieder eine externe Referenz oder Messung des 1kHz-Signals.
>>
>> Habe ich ja geschrieben: die externe Referenz ist die Systemzeit und die
>> Messung vermittelt, wieviele Samples in der gegebenen Zeit abgespielt
>> wurden.
>
> Ich hatte Dich so verstanden, daß Du die Frequenz des 1kHz-Signals
> messen/prüfen willst.

Ja - aber bei genauer Betrachung ergibt die sich ja aus der Zahl der
Samples, die übertragen wurde. Ich hatte mich da vermutlich ungeschickt
ausgedrückt.

Arno Welzel

unread,

Jul 20, 2022, 8:32:14 AM7/20/22

to

Helmut Schellong:

> On 07/17/2022 22:21, Arno Welzel wrote:
>> Helmut Schellong:
>>
>>> On 07/17/2022 13:59, Arno Welzel wrote:
>>>> Helmut Schellong:
>> [...]
>>>>> Die RTC im PC ist nun mal per Quarz getaktet, per CR2032.
>>>>> Auch 150 s Abweichung wären egal gewesen.
>>>>
>>>> Ja, hast du schon gesagt. War dennoch nicht das Thema.
>>>
>>> Das mit den 150 s hatte ich wohl nur einmal geschrieben.
>>
>> Nein, dass Dir größere Abweichungen und deren schlagartige Korrektur
>> beim NTP-Sync egal sind, das hast Du mehr als einmal geschrieben.
>
> Und ich hatte dabei schon selbst geschrieben, daß ich das
> bereits geschrieben hatte.
>
> Das mit den 150 s hatte ich NUR in 07/16/2022 20:55 geschrieben.
> Also 1-mal, wie ich stark vermutete.

Darum ging es mir aber nicht, sondern um "wären egal gewesen".

[...]

> Skalieren kann man dann später mit einem Faktor.

Den Faktor muss man aber kennen.

Arno Welzel

unread,

Jul 20, 2022, 8:33:41 AM7/20/22

to

Helmut Schellong:

> On 07/18/2022 21:10, Marc Haber wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>>> Ist mir schnuppe!
>>
>> Aber die Server der PTB benutzen anstelle eines Poolservers.
>>
>
> ptbtime ist ein Kommando, das ich vielleicht einmal pro Monat aufrufe.
> Das ist vollkommen vernachlässigbar.

Du bist aber nicht der Einzige. Und wenn Alle so denken würden, wie Du,
hat die PTB irgendwann ein Problem. Genau deshalb hat man ja NTP-Pools
eingeführt, um die Last zu verteilen.

Marc Haber

unread,

Jul 20, 2022, 8:51:37 AM7/20/22

to

Interessanterweise möchte die PTB ausdrücklich, dass man ihre Server
benutzt, und zwei unter anderem weil sie das Verhalten von NTP-Servern
unter Last untersuchen wollen. Das war zumindest die Auskunft, die ich
vor Jahren von der PTB erhielt.

Aber wenn man die schon benutzt, dann doch bitte mit einem Tool das es
richtig macht und nicht mit ntpdate.

Grüße
marc

Gerrit Heitsch

unread,

Jul 20, 2022, 9:41:59 AM7/20/22

to

On 7/20/22 14:51, Marc Haber wrote:
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Helmut Schellong:
>>
>>> On 07/18/2022 21:10, Marc Haber wrote:
>>>> Helmut Schellong <r...@schellong.biz> wrote:
>>>>> Daran ist erkennbar, daß meine Systemzeit um 28 Sekunden abgewichen war.
>>>>> Ist mir schnuppe!
>>>>
>>>> Aber die Server der PTB benutzen anstelle eines Poolservers.
>>>>
>>>
>>> ptbtime ist ein Kommando, das ich vielleicht einmal pro Monat aufrufe.
>>> Das ist vollkommen vernachlässigbar.
>>
>> Du bist aber nicht der Einzige. Und wenn Alle so denken würden, wie Du,
>> hat die PTB irgendwann ein Problem. Genau deshalb hat man ja NTP-Pools
>> eingeführt, um die Last zu verteilen.
>
> Interessanterweise möchte die PTB ausdrücklich, dass man ihre Server
> benutzt, und zwei unter anderem weil sie das Verhalten von NTP-Servern
> unter Last untersuchen wollen. Das war zumindest die Auskunft, die ich
> vor Jahren von der PTB erhielt.
>
> Aber wenn man die schon benutzt, dann doch bitte mit einem Tool das es
> richtig macht und nicht mit ntpdate.

ntpdate ist nicht falsch. Es stellt die Uhr einmal und fertig. Solaris
hat das z.B. beim Systemboot benutzt um die Uhr zu stellen. Danach wird
dann der ntpd gestartet damit die Uhr auch genau bleibt.

Gerrit