0.1 ppm und besser...

[Helmut Schellong]

On 07/16/2022 12:33, 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.

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

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


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Arno Welzel]

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.

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

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

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Helmut Schellong]

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

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Stefan Wiens]

Arno Welzel <usenet@arnowelzel.de> writes:

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.

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

--
Stefan

 

[Stefan Wiens]

Arno Welzel <usenet@arnowelzel.de> writes:

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.

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

--
Stefan

 

[Arno Welzel]

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
https://arnowelzel.de

 

[Arno Welzel]

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.


--
Arno Welzel
https://arnowelzel.de

 

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

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

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\'.

--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Thomas Einzel]

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]

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]

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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Michael Schwingen]

On 2022-07-16, Helmut Schellong <rip@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]

On 2022-07-16, Rupert Haselbeck <mein-rest-muell@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]

On 07/17/2022 00:15, Michael Schwingen wrote:

On 2022-07-16, Helmut Schellong <rip@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.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

 

[Michael Schwingen]

On 2022-07-17, Helmut Schellong <rip@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]

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
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong:

On 07/17/2022 00:15, Michael Schwingen wrote:
On 2022-07-16, Helmut Schellong <rip@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
https://arnowelzel.de