PGP-Key: [DH/DSS] 4096-bit 0xE10F502E; verschlüsselte Kommunikation erwünscht.
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 Skripte 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:
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.
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)'.
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.
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 oder mehrere Timeserver und synchronisiert die Systemzeit mit diesen. Gleichzeitig kann es als Timeserver für andere Rechner im LAN dienen. Wer Debian verwendet, wird fast alle folgenden Skripte 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 den Skripten '/etc/init.d/hwclock.sh' und '/etc/init.d/hwclockfirst.sh'. Hier genügt ein 'exit 0' am Anfang, um das Skript 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.
chrony besteht aus zwei Teilen: Das Clientprogramm chronyc bildet die Benutzerschnittstelle sowie der eigentliche Server chronyd, der beim Booten gestartet wird und die Kontrolle über die Systemzeit und RTC übernimmt. Der Start erfolgt bei Debian mit folgendem Skript:
#! /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 Skript 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 Mark Trettin folgendes Skript zur Verfügung gestellt:
#! /bin/sh # chronyd-Startskript für SuSE 8.2 # /etc/init.d/chronyd # # Symbolischer link nach: # /sbin/rcchronyd # ### BEGIN INIT INFO # Provides: chronyd # Required-Start: $syslog $remote_fs # X-UnitedLinux-Should-Start: $time ypbind sendmail # Required-Stop: $syslog $remote_fs # X-UnitedLinux-Should-Stop: $time ypbind sendmail # Default-Start: 2 3 5 # Default-Stop: 0 1 2 6 # Short-Description: chrony daemon providing RTC-Updates # Description: Start chronyd to gradually correct the Systemclock. ### END INIT INFO DESC="chronyd"; # Gucken, ob's überhaupt da ist. CHRONYD_BIN=/usr/local/sbin/chronyd test -x $CHRONYD_BIN || exit 5 # Konfig Files da? CHRONYD_CONFIG=/etc/chrony.conf test -r $CHRONYD_CONFIG || exit 6 # Die ganzen netten Funktionen laden... . /etc/rc.status # Status zurücksetzen. rc_reset case "$1" in start) echo -n "Starting $DESC " ## Start daemon mit startproc(8). startproc $CHRONYD_BIN -r -s rc_status -v ;; stop) echo -n "Shutting down $DESC " ## Stop daemon mit killproc(8) killproc -TERM $CHRONYD_BIN rc_status -v ;; try-restart) $0 status >/dev/null && $0 restart rc_status ;; restart) $0 stop $0 start rc_status ;; force-reload) echo -n "Reload service $DESC " killproc -HUP $CHRONYD_BIN rc_status -v ;; reload) echo -n "Reload service $DESC " killproc -HUP $CHRONYD_BIN rc_status -v ;; status) echo -n "Checking for service $DESC " checkproc $CHRONYD_BIN rc_status -v ;; *) echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload}" exit 1 ;; esac rc_exit |
Zusätzliche Änderungen für die Installation unter SuSE:
1. Obiges Skript nach /etc/init.d/chronyd packen 2. ln -s /etc/init.d/chronyd /(usr/)sbin/rcchronyd 3. inserv /etc/init.d/chronyd (Hiermit werden die Links in /etc/init.d/rc?.d erzeugt)
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 Mark Trettin für die SuSE-spezifischen Beiträge!
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 134.130.4.17 minpoll 8 offline server 195.145.119.188 minpoll 8 offline server 130.149.17.21 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 192.168.0 cmdallow 192.168.0.1 logchange 1.0 mailonchange [email protected] 1.0 |
Am Anfang stehen verschiedene Zeitserver, die chrony bei Bedarf abfragen soll. In meinem Fall sind es Timeserver in Aachen und Berlin sowie der Timeserver von T-Online. 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 Skript 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 Angaben 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 (in parts per million) fest, 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, in diesem Fall für alle Rechner, die eine IP aus dem Bereich 192.168.0.x besitzen. Die Direktive 'cmdallow 192.168.0.1' besagt, daß das Clientprogramm chronyc nur vom Rechner mit der IP-Adresse 192.168.0.1 Kommandos an das Serverprogramm chronyd schicken darf. Natürlich möchte ich auch informiert werden, wenn die Zeit einmal falsch gehen sollte. Dafür sorgen die beiden Optionen 'logchange 1.0' und 'mailonchange [email protected] 1.0'. Die erste Option sorgt dafür, daß eine Meldung via Syslog protokolliert wird, wenn die Zeitabweichung größer als 1 s ist, während die zweite Option mir eine Mail schickt (ebenfalls bei einer Abweichung von 1 s).
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
Dieses Protokoll benutzt Port 37/TCP, während NTP den
Port 123/UDP benutzt. Zusätzlich benötigt
chrony noch den Port 323/UDP zu Kommunikation
zwischen chronyc und chronyd, dies ist beim Einsatz
eines Paketfilters zu beachten!
Damit chrony weiß, wann die Verbindung ins Internet steht, wird nach einem Dialup folgendes Skript 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 Skript chrony wieder 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 Skripte 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 Skript:
#! /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 Skript 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 Skript 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.
marcus@iridium:~$ chronyc tracking Reference ID : 130.149.17.21 (hora.cs.tu-berlin.de) Stratum : 2 Ref time (UTC) : Fri Jun 20 13:44:55 2003 System time : 0.000000 seconds fast of NTP time Frequency : 75.013 ppm fast Residual freq : -0.002 ppm Skew : 0.187 ppm Root delay : 0.073181 seconds Root dispersion : 0.000748 seconds |
'chronyc rtcdata' liefert Informationen über die Abweichung der RTC gegenüber der Systemzeit:
marcus@iridium:~$ chronyc rtcdata RTC ref time (UTC) : Fri Jun 20 14:00:15 2003 Number of samples : 9 Number of runs : 5 Sample span period : 23m RTC is fast by : 0.957581 seconds RTC gains time at : -2.556 ppm |
Und mit 'chronyc sources' bzw. 'chronyc sourcestats' erhältst Du Informationen über die Verfügbarkeit der Timeserver:
marcus@iridium:~$ chronyc sources 210 Number of sources = 10 MS Name/IP address Stratum Poll LastRx Last sample ============================================================================ ^+ ts-1.rz.RWTH-Aachen.DE 1 10 932 +9713us[+9618us] +/- 57ms ^+ ts-2.rz.RWTH-Aachen.DE 2 10 413 +9950us[+9848us] +/- 77ms ^+ ntp1.t-online.de 1 10 430 +925us[ +824us] +/- 40ms ^? www1.rrz.Uni-Koeln.DE 3 10 503 -699us[ -799us] +/- 77ms ^* hora.cs.tu-berlin.de 1 8 26 +2054us[+1947us] +/- 49ms ^+ rustime01.rus.uni-stuttga 1 10 685 +1047us[ +949us] +/- 34ms ^+ rzfs2.rz.tu-bs.de 2 10 312 -1038us[-1141us] +/- 38ms ^+ ns1.hrz.uni-giessen.de 2 10 743 +6974us[+6877us] +/- 71ms ^? ntp2-rz.rrze.uni-erlangen 0 10 32 +0us[ +0us] +/- 0us ^+ mailbox.TU-Berlin.DE 2 10 755 -1253us[-1350us] +/- 37ms |
marcus@iridium:~$ chronyc sourcestats 210 Number of sources = 10 Name/IP Address NP NR Span Frequency Freq Skew Std Dev ======================================================================== ts-1.rz.RWTH-Aachen.DE 30 15 322m 0.201 0.324 2673us ts-2.rz.RWTH-Aachen.DE 18 10 226m -1.381 0.743 4022us ntp1.t-online.de 22 13 311m -0.052 0.146 1065us www1.rrz.Uni-Koeln.DE 30 13 345m 0.118 0.291 2871us hora.cs.tu-berlin.de 64 34 319m -0.004 0.183 2451us rustime01.rus.uni-stuttga 23 12 298m -0.130 0.229 1627us rzfs2.rz.tu-bs.de 26 11 315m -0.090 0.213 1656us ns1.hrz.uni-giessen.de 26 12 315m 0.038 0.300 2231us ntp2-rz.rrze.uni-erlangen 0 0 0 -0.413 2000.000 4000ms mailbox.TU-Berlin.DE 23 11 313m -0.042 0.282 2085us |
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)
Homepage des NTP Protokolls
Liste öffentlicher Timeserver (international)
Weitere Zeitserver (deutsch)
|
Last modified: Sun Dec 27 21:31:45 CEST 2009 durch Marcus Frings PGP-Key: [DH/DSS] 4096-bit 0xE10F502E; verschlüsselte Kommunikation erwünscht. |