0.1 ppm und besser...

[Arno Welzel]

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

 

[Arno Welzel]

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

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>


--
Arno Welzel
https://arnowelzel.de

 

[Michael Schwingen]

On 2022-07-17, Arno Welzel <usenet@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]

On 2022-07-17, Arno Welzel <usenet@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]

On 07/17/2022 13:34, Michael Schwingen wrote:

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.

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.



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


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

Michael Schwingen:

On 2022-07-17, Arno Welzel <usenet@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.


--
Arno Welzel
https://arnowelzel.de

 

[Leo Baumann]

Am 17.07.2022 um 22:17 schrieb Arno Welzel:

Michael Schwingen:

On 2022-07-17, Arno Welzel <usenet@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.

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

Grüße

 

[Arno Welzel]

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.


--
Arno Welzel
https://arnowelzel.de

 

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

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

--
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, Arno Welzel <usenet@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]

Helmut Schellong <rip@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]

On 07/18/2022 21:10, Marc Haber wrote:

Helmut Schellong <rip@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.


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

 

[Bernd Laengerich]

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]

On 2022-07-19, Bernd Laengerich <Bernd.Laengerich@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]

Michael Schwingen:

On 2022-07-17, Arno Welzel <usenet@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
https://arnowelzel.de

 

[Arno Welzel]

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

 

[Arno Welzel]

Helmut Schellong:

On 07/18/2022 21:10, Marc Haber wrote:
Helmut Schellong <rip@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.


--
Arno Welzel
https://arnowelzel.de

 

[Marc Haber]

Arno Welzel <usenet@arnowelzel.de> wrote:

Helmut Schellong:

On 07/18/2022 21:10, Marc Haber wrote:
Helmut Schellong <rip@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.

Grüße
marc
--
-------------------------------------- !! 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

 

[Gerrit Heitsch]

On 7/20/22 14:51, Marc Haber wrote:

Arno Welzel <usenet@arnowelzel.de> wrote:
Helmut Schellong:

On 07/18/2022 21:10, Marc Haber wrote:
Helmut Schellong <rip@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