Format der Log/Stats Dateien für z.B Gnuplot verstehen
Aufbau der loopstats Datei:
$ tail /var/log/ntpstats/loopstats
60544 33446.545 -0.000000280 -3.309 0.000006801 0.000180 4
1. Datum (Modifiziertes Julianisches Datum).
2. Sekunden und Teile seit Mitternacht (UTC).
3. Uhren-Offset zur Referenz in Sekunden.
4. Frequenz-Offset der Systemuhr in PPM.
5. Lokales RMS Time Jitter in Sekunden.
6. RMS Frequenz Jitter („wander oder auch Allan Deviation“) in PPM.
7. Clock-discipline Zeitkonstante (Polling-Intervall).
Aufbau der peerstats Datei:
59020 1.005 127.127.22.2 97fa 0.000001568 0.000000000 0.000231793 0.000001714
1. Datum (Modifiziertes Julian Tag Format in Monat-Jahr-Tag)
2. Sekunden & ms seit UTC Mitternacht
3. IP Adresse
4. Status
5. Clock Offset in Sekunden & Nano Sekunden
6. Roundtrip Delay in Sekunden & Nano Sekunden
7. Dispersion in Sekunden & Nano Sekunden
8. RMS Jitter / skew (variance)
Probleme mit der Schaltsekunden Datei bei Versionen < 4.2.6
Version 4.2.6 ist zwar schon echt alt, aber da sie auf dem Lantime Server fest eingebaut ist stellt sich schon manchmal die Frage warum es nicht klappt.
Alles AB Version 4.2.6 –> Eintrag in der ntp.conf: leapfile „pfad/leap-seconds.list“ und fertig.
Alles UNTER 4.2.6 –> Kein Eintrag mit der Pfadangabe, Keyword ‚leapfile‘ ist unbekannt und wirft Fehler im Log raus.
Autokey MUSS leider an sein, das heutzutage ja als sehr unsicher gilt.
Eintrag in der ntp.conf: keys /etc/ntp/ntp.key # MD5 Keyfile
Noch ein Eintrag in der conf: keysdir /etc/ntp/
Zum Schluss noch einen Symlink ntpkey_leap zur eigentlichen Leapfile setzten.
Tool ntptime
This program is useful only with special kernels described in the A Kernel Model for Precision Timekeeping page. It reads and displays time-related kernel variables using the ’ntp_gettime()‘ system call. A similar display can be obtained using the ’ntpdc‘ program and ‚kerninfo‘ command.
-t timeconstant
Set the log2 of PLL time constant, an integer in the range 0-10.
- Probleme mit dem ntpdc Programm:
Da es mittlerweile als unsicher angesehen wird, wurden viele Befehle deaktiviert. Eigentlich lässt sich mittlerweile aber auch soweit alles mit ’ntpq‘ erledigen, da die meisten Funktionen dort hin gewandert sind.
Allerdings muss der Host auf Localhost gesetzt werden:
ntpq
host 127.0.0.1
authinfo, mrulist, lpeers, monstats, sysinfo, sysstats … was auch immer.
Tool ntpq
Im Status eines NTP-Servers (z. B. bei ntpq -c rv) gibt die Angabe precision die kleinste Zeiteinheit an, die das System noch unterscheiden kann.
Der Wert ist dabei als Zweierpotenz im Logarithmus dargestellt, also precision=-22 bedeutet 2−222−22 Sekunden ≈ 238 Nanosekunden, während precision=-20 2−202−20 Sekunden ≈ 953 Nanosekunden entspricht.
Also 1 Sekunde / 2e22 ≈ 238 Nanosekunden.
- precision = -16 entspricht etwa 15 µs,
- precision = -20 etwa 1 µs,
- precision = -21 etwa 0,477 µs (477 ns) [Skuld],
- precision = -22 etwa 0,24 µs (238 ns) [Urd],
- precision = -23 etwa 0,119 µs (119 ns) [Verdandi],
- precision = -24 etwa 0,06 µs (60 ns).
Ein niedrigerer Wert (z. B. 2e-22) steht für eine höhere Präzision, also
das feinere Zeitauflösungsvermögen des Systems.
Praktisch ist eine höhere Präzision (niedrigerer Wert) besser, da das System kleinere Zeitdifferenzen erkennt.
Allerdings hängt die tatsächliche Synchronisationsgenauigkeit auch stark von der Hardware (z. B. Taktgeber) und den
Betriebsbedingungen (Jitter, Latenz) ab.
Eine Angabe von precision=2e-22 ist generell besser als precision=2e-20, da sie eine genauere Zeitmessung im NTP-Status dokumentiert.
Mit ntpq -pu wird der Offset etc. direkt in Zeiteinheiten angeben, was genauer in der Auflösung ist.
ntpq -p
LOCAL(0) .LOCL. 12 l – 64 0 0.0000 0.0000 0.0002
*SHM(0) .GPSs. 0 l 1 16 377 0.0000 -0.0002 0.0001
SHM(1) .PZFs. 0 l 9 16 377 0.0000 -0.0629 0.0002
PPS(0) .PPS. 0 l 9 16 377 0.0000 0.0685 0.0013
ntpq -pu
LOCAL(0) .LOCL. 12 l – 64 0 0ns 0ns 238ns
*SHM(0) .GPSs. 0 l 9 16 377 0ns -109ns 171ns
SHM(1) .PZFs. 0 l 1 16 377 0ns -62.42us 434ns
PPS(0) .PPS. 0 l 1 16 377 0ns 69.592us 1.768us