Leider hat Berthold Müller, der ursprüngliche Verfasser, keine Zeit mehr, diese Seite zu pflegen und hat zudem alle seine weiteren Webseiten vom Netz genommen. Da aber seine Seite zu chrony meiner Meinung nach eine wichtige Referenz war und ist und auch mir damals sehr geholfen hat, finde ich es äußerst schade, wenn so etwas einfach so verschwinden sollte... Berthold war auf meine Anfrage so freundlich, mir den Quelltext zu schicken, so daß seine Seite ab jetzt unter dieser Adresse http://www.sc-delphin-eschweiler.de/chrony/index.html zu finden sein wird! Ich habe sie zunächst einmal im Original übernommen und werde in Zukunft die Seite weiter pflegen.

Marcus Frings

Alle Jahre wieder, zu Beginn und Ende der Sommerzeit, tauchen dieselben Postings auf: "Hilfe, meine Uhr geht 2 Stunden verkehrt!" oder "Ich habe die Uhr gestellt, jetzt stimmt sie nach dem Booten überhaupt nicht mehr." Aus diesem Grund und weil ich schon seit langer Zeit chrony erfolgreich einsetze, habe ich diese Seite geschrieben.

Die Beschreibung bezieht sich auf meinen Dialup-Rechner, auf dem Debian GNU/Linux installiert ist. Sie soll kein Ersatz für die reichlich vorhandene Dokumentation zu den einzelnen Programmen sein, sondern nur den Einstieg erleichtern, um chrony möglichst schnell zum Laufen zu bekommen. Viele Scripte sind sicher Debian-spezifisch, aber die Anpassung an andere Distributionen sollte nicht allzu schwierig sein. Auf die (mir bekannten) Änderungen für SuSE und Mandrake wird an passender Stelle hingewiesen. Weitere Hinweise sind jederzeit willkommen.

Zum besseren Verständnis der Arbeitsweise von chrony zunächst einige allgemeine Informationen zu den verschiedenen Uhren:

1. Die Uhren eines PC

In einem PC gibt es eine Realtime Clock (RTC), auch Hardware Clock oder CMOS Clock genannt. Das ist ein kleiner Chip, der unabhängig von irgendwelcher Software ist und auch funktioniert wenn der Rechner ausgeschaltet ist. Dazu dient eine kleine Batterie oder ein Akku. Als typisches Massenprodukt erreicht sie natürlich nicht die Genauigkeit, die ich von einer Uhr erwarte. Die Abweichung hängt u. a. ab von den Fertigungstoleranzen, dem Alterungsprozess und der Temperatur des Schwingquarzes. Der Schwingquarz ist das frequenzbestimmende Bauteil, von dem der Sekundentakt abgeleitet wird. In meinem Rechner z. B. beträgt die Abweichung der RTC bei ausgeschaltetem Rechner ca. 5 s pro Tag.

Unter Linux wird die RTC nur als Zwischenspeicher der Uhrzeit während der Zeit genutzt, in der Linux nicht aktiv ist. Wird Linux gebootet, wird die Systemzeit, eine Softwareuhr die vom Kernel verwaltet wird, einmal aus der RTC geladen. Damit ergibt sich ein Problem, wenn die RTC auf lokaler Zeit läuft und zu Beginn oder Ende der Sommerzeit vergessen wird sie rechzeitig umzustellen, denn Linux berücksichtigt beim Laden der Systemzeit, die immer auf UTC läuft, automatisch den Zeitunterschied zwischen UTC und lokaler Zeit; d. h. die Systemzeit kann falsch gehen. Ist kein anderes Betriebsystem auf dem Rechner installiert, das die RTC auf lokaler Zeit erfordert, ist es also grundsätzlich die bessere Wahl, die RTC auf UTC laufen zu lassen - dann stellt sich dieses Problem erst gar nicht.

Die Systemzeit ist im Prinzip ein Zähler, der die Anzahl Sekunden seit dem 1970-01-01 00:00:00 UTC enthält und von einem Timer Interrupt aufdatiert wird. Dieser Interrupt ist abhängig von einem Quarzoszillator auf dem Motherboard und damit ist die Genauigkeit der Systemzeit von den gleichen Faktoren abhängig wie die RTC, aber unabhängig von dieser, d. h. sowohl die RTC als auch die Systemzeit unter Linux besitzen eine absolute Abweichung von der tatsächlichen Zeit und zusätzlich eine temperaturabhängige und alterungsbedingte Drift.

2. Die Darstellung von Datum und Uhrzeit

Unter Windows ist die RTC die einzige Uhr im System und läuft normalerweise auf der lokalen = Ortszeit, wobei Windows die Umstellung auf Sommerzeit/Winterzeit direkt an der RTC vornimmt. Diese Tatsache ist von Bedeutung, wenn Du unter Linux die Uhren von chrony synchronisieren läßt; siehe weiter unten. Zur Darstellung von Datum und Uhrzeit nimmt Windows die Werte direkt aus der RTC.

Auch unter Linux läßt sich die RTC setzen und auslesen, dazu dient das Programm hwclock. Das Kommando 'hwclock --show' zeigt die aktuelle Uhrzeit an. Mit dem zusätzlichen Parameter '--utc' bzw. '--localtime' kannst Du dem Programm mitteilen, ob die RTC auf UTC oder lokaler Zeit läuft. Eine sehr schöne Möglichkeit das Jahrtausendproblem älterer Biosversionen zu umgehen, bietet die Option '--badyear'. Für nähere Information verweise ich auf die manpage zu diesem Programm.

Da unter Linux, wie weiter oben beschrieben, die Systemzeit nur auf einem Zähler basiert, braucht das System zur korrekten Darstellung der lokalen Zeit noch Informationen über die Zeitzone. Diese läßt sich mit dem Programm tzconfig recht einfach einstellen. Für Deutschland gilt: Zeitzone = 'Europe/Berlin' und die Zeitangabe ist 'CET', bzw. 'CEST' während der Sommerzeit. Zur Kontrolle: Bei richtiger Einstellung enthält '/etc/timezone' den Wert 'Europe/Berlin' und '/etc/localtime' ist ein Link auf '/usr/share/zoneinfo/Europe/Berlin'. (Dies gilt für Debian, bei anderen Distributionen kann die Pfadangabe anders lauten.)

Um die Systemzeit darstellen oder setzen zu können, gibt es das Programm date. Dieses bietet eine Menge Optionen und erlaubt somit einen sehr flexiblen Zugriff auf die Softwareuhr des Kernels. Die einfachste Form ist der Aufruf 'date' ohne Parameter. Damit wird das aktuelle Datum und die Uhrzeit ausgegeben. Die Darstellung berücksichtigt automatisch die festgelegte Zeitzone und die Umschaltung der Sommer/Winterzeit. Bitte beachten: die Systemzeit (Softwareuhr des Kernels) selbst wird dadurch nicht verändert - sie läuft immer auf UTC!

Die Darstellung von Datum und Uhrzeit nach ISO-8601 liefert: 'echo $(date -I;date +%T)'.

3. Manuelles Korrigieren der Uhren

Nachdem wir nun festgestellt haben, wie ungenau die Uhren eines Rechners sind, wird es Zeit sie mal zu stellen. Ich beginne mit der Systemzeit unter Linux. Das Programm date bietet verschiedene Möglichkeiten des Datumformats, ich bevorzuge die Form nach ISO-8601: "YYYY-MM-TT hh:mm:ss". Ein Aufruf von 'date -s "2001-04-23 19:34:30"' setzt die Systemzeit auf den angegebenen Wert.

Dieses einmalige Setzen der Systemzeit hat natürlich keinen Einfluß auf die Drift der Softwareuhr. Um diese zu korrigieren gibt es das Programm adjtimex, das eine sehr feine Einstellung der einzelnen "Ticks" erlaubt. Dabei wird die Systemzeit mehrmals mit einer sehr genauen Uhr synchronisiert. Macht man die Intervalle sehr lang - einige Tage - läßt sich auf diese Weise eine erstaunliche Genauigkeit der Systemzeit erreichen, vor allem, wenn der Rechner die ganze Zeit durchläuft. Für einen Rechner ohne Internetzugang ist das eine gute Alternative. Da ein Internetzugang heute aber schon fast Standard ist, will ich nicht näher darauf eingehen.

Um die RTC zu stellen, gibt es verschiedene Möglichkeiten. Du kannst sie z. B. beim Booten direkt im BIOS stellen. Eine andere Möglichkeit ist das schon erwähnte Programm hwclock mit der zugehörigen Datei '/etc/adjtime'. Damit hat es folgendes auf sich:

Immer, wenn die RTC mit hwclock verändert wird, werden der Zeitpunkt der Änderung und die Abweichung von der Systemzeit in diese Datei geschrieben. Mit diesen Informationen und der Option '--adjust' ist hwclock in der Lage, Abweichungen der RTC bis zu einem gewissen Grad zu korrigieren. Das Problem liegt darin, daß sich die RTC nur in einem festen Sekundenraster stellen läßt; ein Restfehler bleibt also. Wenn dir das jetzt alles zu theoretisch war, führe einfach mal 'hwclock --test --debug --systohc --utc' aus. Keine Angst, durch die Option '--test' wird dabei das Stellen der RTC nur simuliert und nichts weiter verändert. Zur Bedeutung der einzelnen Einträge in '/etc/adjtime' verweise ich auf die manpage zu hwclock.

Sollte durch irgendwelche Umstände die Systemzeit mal total durcheinander geraten sein, hier ein einfaches Rezept um wieder klare Verhältnisse zu schaffen:

    1. Stelle die richtige Zeitzone ein.
    2. Setze die Systemzeit wie oben beschrieben. ('date -s "YYYY-MM-TT hh:mm:ss"')
    3. Lösche die Datei '/etc/adjtime'.
    4. Setze die RTC mit: 'hwclock --debug --systohc --utc'.
       (Läuft die RTC auf lokaler Zeit, verwende statt '--utc' die Option '--localtime').
    5. Wiederhole Punkt 3 und 4.    

Außerdem ist folgendes zu beachten:

Läuft die RTC auf lokaler Zeit, ist zu Beginn und Ende der Sommerzeit vor dem Start von Linux als erstes die RTC auf die richtige Zeit zu setzen, dann erfolgt auch unter Linux das richtige Laden der Systemzeit. Ist neben Linux noch Windows installiert, so kannst Du diesem die Umstellung der RTC überlassen, indem Du es als erstes nach der Zeitumstellung bootest. Das ist IMO der einfachste Weg.

4. Automatische Korrektur der Uhren mit chrony

Das manuelle Korrigieren der Uhrzeit kann eine sehr zeitraubende Angelegenheit werden, vor allem wenn man mehrere Rechner betreut. Aber es gibt ja chrony, das die oben beschriebenen Vorgänge automatisiert und sich die genaue Uhrzeit aus dem Internet holt. Nach dem Einrichten brauchst Du dich nie mehr um die richtige Uhrzeit kümmern.

Damit chrony funktioniert, ist eine Bedingung Voraussetzung: '/dev/rtc' muß existieren und zugänglich sein. Ob das der Fall ist, läßt sich leicht mit folgender Anweisung herausfinden:

    hwclock --debug --show

Achtung: Wenn '/dev/rtc' schon von einer anderen Anwendung, z. B. chrony, belegt ist, kann die Meldung irreführend sein!

Falls nötig, ist der 'Enhanced RTC Support' in den Kernel zu kompilieren, bzw. das Modul zu laden. Das geschieht bei SuSE durch den Eintrag "alias char-major-10-135 rtc" in '/etc/modules.conf'.

Im Prinzip vereint chrony in sich die Fähigkeiten von adjtimex und hwclock. Es kontaktiert von Zeit zu Zeit einen Timeserver und synchronisiert die Systemzeit darauf. Gleichzeitig kann es als Timeserver für andere Rechner im LAN dienen. Wer Debian verwendet, wird fast alle folgenden Scripts nach der Installation schon vorfinden, für alle anderen können sie als Anhaltspunkt für die eigene Konfiguration dienen. Im übrigen möchte ich auf die gute und ausführliche Dokumentation zu chrony verweisen. Diese Seite kann und soll auch nicht alle Distributionen abdecken, dazu sind sie zu verschieden.

Damit chrony seine Aufgabe einwandfrei erfüllen kann, muß sichergestellt sein, daß niemand außer chrony die Uhren verändert! Unter Debian geschieht das in dem Script '/etc/init.d/hwclock.sh'. Hier genügt ein 'exit 0' am Anfang um das Script zu deaktivieren. Um sicher zu gehen, daß keine weiteren Aufrufe von hwclock erfolgen, kannst Du mit 'cd /etc; find -type f | xargs grep hwclock -l' z. B. im Verzeichnis '/etc' rekursiv danach suchen. Bei Mandrake befindet sich der betreffende Abschnitt in der Datei 'halt' und ist auszukommentieren.

5. Die Konfiguration von chrony

chrony besteht aus zwei Teilen, chronyc das die Benutzerschnittstelle bildet und chronyd das beim Booten gestartet wird und die Kontrolle über die Systemzeit und RTC übernimmt. Der Start erfolgt bei Debian mit folgendem Script:

#! /bin/sh
# /etc/init.d/chrony (Version für Debian)
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/chronyd
DESC="chronyd"
FLAGS="defaults"
test -f $DAEMON || exit 0
case "$1" in
  start)
    start-stop-daemon --start --verbose --exec $DAEMON -- -r -s ;;
  stop)
    start-stop-daemon --stop --verbose --exec $DAEMON ;;
  restart)
    echo -n "Restarting $DESC: .."
    start-stop-daemon --stop --quiet --exec $DAEMON
    sleep 1
    start-stop-daemon --start --quiet --exec $DAEMON -- -r -s
    echo "done." ;;
  *)
    echo "Usage: /etc/init.d/chrony {start|stop|restart}"
    exit 1 ;;
esac
exit 0

Das Script bietet nichts besonderes, nur die Parameter '-- -r -s' habe ich hinzugefügt, damit chrony nach dem Booten auf ältere Samples der Timeserver zurückgreifen kann und die Systemzeit aus der RTC unter Berücksichtigung der Drift geladen wird. chrony führt nämlich Buch über die Abweichung der Systemzeit gegenüber der tatsächlichen Zeit und die Abweichung der RTC gegenüber der Systemzeit. Damit ist die Gesamtabweichung der Uhren auch nach mehreren Tagen Auszeit kleiner als 1 s.

Für SuSE hat mir Thomas Kosch folgendes Script zur Verfügung gestellt:

#! /bin/sh
# /etc/init.d/chrony (Version für SuSE)
. /etc/rc.status
. /etc/rc.config
DAEMON=/usr/local/sbin/chronyd
DESC="chronyd"
FLAGS="defaults"
test -f $DAEMON || exit 0
case "$1" in
  start)
    echo -n "Starting $DESC"
    startproc $DAEMON -r -s
    rc_status -v ;;
  stop)
    echo -n "Shutting down $DESC"
    killproc -TERM $DAEMON
    rc_status -v ;;
  restart)
    echo -n "Restarting $DESC: .."
    $0 stop
    sleep 1
    $0 start
    echo "done." ;;
  *)
    echo "Usage: /etc/init.d/chrony {start|stop|restart}"
    exit 1 ;;
esac
exit 0

Zusätzliche Änderungen für die Installation unter SuSE:

In die rc.config START_CHRONY="yes" eintragen und folgende Links anlegen:
(Dies gilt für SuSE 7.2, für ältere müßten die Links nach 1,2,3 zeigen)

    /etc/init.d/rc2.d/K13chrony
    /etc/init.d/rc2.d/S08chrony
    /etc/init.d/rc3.d/K13chrony
    /etc/init.d/rc3.d/S08chrony
    /etc/init.d/rc5.d/K13chrony
    /etc/init.d/rc5.d/S08chrony

Die folgenden Default-Pfadangaben für SuSE sind für die weiter unten beschriebenen Konfigurationsdateien von Bedeutung:

    /etc/chrony.conf
    /etc/chrony.drift
    /etc/chrony.keys
    /etc/chrony.rtc
    /usr/local/bin/chronyc
    /usr/local/doc/chrony
    /usr/local/sbin/chronyd
    /var/log/chrony

Außer dem ersten sind die übrigen Pfade über chrony.conf frei wählbar. Wer sich also große Änderungen ersparen will, kopiert nur chrony.conf nach '/etc/' und kann die übrigen Pfadangaben (bis auf chronyc und chronyd) beibehalten.

Vielen Dank an Thomas Kosch und Marcus Frings für ihre Unterstützung!

Wie fast jedes Programm braucht auch chrony eine Konfigurationsdatei. Diese befindet sich unter '/etc/chrony/' und die vorgestellte Datei kann als Anhaltspunkt für Deine eigene Konfiguration dienen. Für meinen Rechner sieht sie so aus:

# /etc/chrony/chrony.conf
server          130.149.4.11   minpoll 8 offline
server          134.95.192.172 minpoll 8 offline
server          137.248.1.8    minpoll 8 offline
keyfile         /etc/chrony/chrony.keys
commandkey      1
rtcfile         /var/lib/chrony/chrony.rtc
driftfile       /var/lib/chrony/chrony.drift
dumpdir         /var/lib/chrony
logdir          /var/log/chrony
log             tracking
dumponexit
maxupdateskew   100.0
rtconutc
allow

Am Anfang stehen verschiedene Zeitserver, die chrony bei Bedarf abfragen soll. In meinem Fall sind es Server in Berlin, Köln und Marburg. Der Zusatz 'offline' bedeutet, daß chrony mit der Abfrage so lange warten soll, bis der Rechner online ist. Wann das der Fall ist, wird chrony in einem anderen Script mitgeteilt. Es müssen nicht so viele Zeitserver sein, aber zwei, besser drei, solltest Du schon eintragen, damit chrony eine Alternative hat, falls ein Server mal nicht erreichbar ist. Welche Server am besten erreichbar sind und von chrony als Referenz ausgewählt werden, kannst Du sehr leicht in '/var/log/chrony/tracking.log' erkennen.

Die Angabe 'minpoll 8' setzt die Zeitspanne zwischen zwei Polls eines Zeitservers auf 256 s. Per Default pollt chrony jeden Server alle 64 s. Durch Verschiebungen kann sich diese Zeit bei drei Zeitservern auf ca. 21 s verringern. Hast Du 'Dial-on-demand' konfiguriert und beträgt die Timeoutzeit bis zum Auflegen z. B. 60 s, so wird der Rechner in diesem Fall nicht auflegen. Die Pollzeit ist also auf mindestens (Timeoutzeit * Anzahl Server) zu erhöhen, damit auch im ungünstigsten Fall der Rechner sicher die Verbindung trennt. Dies geschieht in Zweierpotenzen (2^6=64 s, 2^7=128 s ...), mit dem Wert 8 sind es also 2^8=256 s.

Die Angabe eines Keyfiles hat etwas mit Sicherheit zu tun. Da Änderungen der Systemzeit kritische Zustände hervorrufen können, sind bestimmte Funktionen mit einem Passwort geschützt. Im einfachsten Fall enthält das Keyfile nur eine Zeile wie diese, mit einer Schlüsselnummer (commandkey) und dem Passwort:

# /etc/chrony/chrony.keys
1 password

Dieses kannst Du natürlich beliebig auswählen - nähere Informationen dazu stehen im Manual zu chrony.

Die Angabe der Pfadnamen zeigen chrony wo es diverse Informationen über die Uhren und Zeitserver speichern soll. 'log tracking' erstellt ein Log über die Abweichungen gegenüber der Referenzzeit. Weitere Optionen für 'log' findest Du im Manual zu chrony. Mit der Option 'dumponexit' erstellt chrony beim Herunterfahren ein Historyfile für jeden Timeserver, in dem die Informationen der letzten Abfragen eingetragen werden, 'maxupdateskew' legt die Grenze fest, (in parts per million) bis zu der die Abweichung der Systemzeit zu einem Zeitserver noch als glaubwürdig angesehen wird. Ist die Abweichung zu groß, wird die Abfrage verworfen. Mit 'rtconutc' wird festgelegt, daß die RTC auf UTC läuft. Sollte sie bei dir auf lokaler Zeit laufen, laß diesen Eintrag einfach weg, 'allow' ist nur interessant, wenn Du chrony als Zeitserver anderen Rechnern im LAN zur Verfügung stellen willst.

Damit Windows-Rechner sich die Zeit von einem Linux-Rechner über ein anderes Protokoll als NTP holen können, z. B. mit dem Tool 'TimeRC.exe' oder 'ws-ping', ist in '/etc/inetd.conf' folgender Eintrag nötig:

    time   stream   tcp   nowait   root   internal

Damit chrony weiß, wann die Verbindung ins Internet steht, wird nach einem Dialup folgendes Script ausgeführt:

#!/bin/sh
# /etc/ppp/ip-up.d/chrony
PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc
password $PASSWORD
online
EOF
exit 0

Nach dem Beenden der Verbindung teilt das folgende Script chronywieder den 'offline' Zustand mit:

#!/bin/sh
# /etc/ppp/ip-down.d/chrony
PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc
password $PASSWORD
offline
EOF
exit 0

Unter SuSE befinden sich die beiden Scripts unter /etc/ppp/ip-up.local bzw. /etc/ppp/ip-down.local und der Aufruf von chronyc muß auf /usr/local/bin/chronyc geändert werden.

Für Mandrake und DSL mittels rp-pppoe sind die beiden Scripts am Ende von /usr/sbin/adsl-connect bzw. am Anfang von /usr/sbin/adsl-stop einzufügen. (Vielen Dank an Jens Wolanke für die Information!)

Mein Rechner ist zu sehr unterschiedlichen Zeiten unterschiedlich lange eingeschaltet, daher wirkt sich die Temperatur am stärksten auf die Abweichung der RTC aus. Durch Versuche habe ich herausgefunden, daß es am günstigsten ist, die RTC regelmäßig im Stundenabstand zu stellen, damit chrony die mittlere Abweichung erfassen kann. Diese Aufgabe übernimmt das folgende Script:

#! /bin/sh
# /usr/local/sbin/setrtc
PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc
password $PASSWORD
trimrtc
writertc
dump
EOF

Auch hier muß unter SuSE der Aufruf von chronyc auf /usr/local/bin/chronyc geändert werden.

Da dies eine typische Aufgabe für cron ist, habe ich das folgende Script hinzugefügt:

(Bei SuSE gehört der Eintrag in die Datei '/etc/crontab'.)

# /etc/cron.d/hwclock: adjust RTC frequently
# Run queue every hour
0 * * * *       root    /usr/local/sbin/setrtc >/dev/null 2>&1

Damit wird obiges Script zu jeder vollen Stunde ausgeführt. Wie man aber in den Logeinträgen leicht sehen kann, erfolgt nicht immer eine Korrektur der RTC, sondern nur dann, wenn die Abweichung größer als 1 s ist. Das macht Sinn, denn wie schon oben erwähnt läßt sich die RTC nur im Sekundentakt stellen.

Nachdem nun chrony installiert und konfiguriert ist, wird es Zeit, sich von der korrekten Arbeitsweise zu überzeugen. Das Kommando, das ich am häufigsten benutze, ist 'chronyc tracking'. Damit wird angezeigt, welchen Timeserver chrony als Referenz benutzt und wie groß die Abweichungen sind. Die Beschreibung der verschiedenen Einträge findest Du im Manual zu chrony. ('TS_1', 'TS_2' usw. sind nur Aliase und stammen aus Einträgen in meiner Datei '/etc/hosts'.)

orion(root):/ chronyc tracking
Reference ID    : 130.149.4.11 (TS_1)
Stratum         : 3
Ref time (UTC)  : Sun Apr  8 07:27:05 2001
System time     : 0.000000 seconds fast of NTP time
Frequency       : 13.900 ppm fast
Residual freq   : 0.009 ppm
Skew            : 1.418 ppm
Root delay      : 0.107819 seconds
Root dispersion : 0.028275 seconds

'chronyc rtcdata' liefert Informationen über die Abweichung der RTC gegenüber der Systemzeit:

orion(root):/ chronyc rtcdata    
RTC ref time (UTC) : Sun Apr  8 08:49:17 2001
Number of samples  : 12
Number of runs     : 7
Sample span period :  19m
RTC is fast by     :     0.664673 seconds
RTC gains time at  :    45.637 ppm

Und mit 'chronyc sources' bzw. 'chronyc sourcestats' erhältst Du Informationen über die Verfügbarkeit der Timeserver:

orion(root):/ chronyc sources 
210 Number of sources = 2
MS Name/IP address           Str  Poll LastRx        Last sample
========================================================================
^* TS_1                        2    8   83m  +3468us[+5028us] +/-   76ms
^+ TS_2                        2    8   83m   +210ms[ +210ms] +/-  280ms

orion(root):/ chronyc sourcestats
210 Number of sources = 2
Name/IP          NP   NR  Span       Freq      Skew      S.D./us
================================================================
TS_1             16    7   14h       0.009       1.322     21806
TS_2             10    5   11h       1.316       2.093     14567

Weitere Links:

Homepage von chrony
Was ist Zeit?
The Time of Internet - Glossary
The Time of Internet - Time Zones
Die Zeitzonen
Greenwich Time: Time Zones by Country
Physikalisch-Technische Bundesanstalt (PTB)
Time Server
Public NTP Time Servers
Weitere Zeitserver