Auch aus diesen Gründen sollte dem ntpd als Standardimplementation der Vorzug gegeben werden. Dieser gleicht Gangdifferenzen zur korrekten Uhrzeit durch Beschleunigung bzw. Verlangsamung der lokalen Systemuhr aus. Stimmt die Zeit wieder, stellt der Daemon die richtige Geschwindigkeit her. Die oben angeführten Nachteile von ntpdate sind damit schon einmal umschifft. Natürlich bringt das eine etwas aufwendigere Konfiguration mit sich, allerdings sollte dies mit den zahlreichen Tutorials im Netz kein Problem sein.
Vereinfacht wird die "richtige" Geschwindigkeit der Systemuhr normalerweise durch einen Baustein auf dem Motherboard bestimmt, wobei ein Quarzkristall x-mal pro Sekunde schwingt. Da es bei solchen Bauteilen allerdings immer auch Fertigungstoleranzen gibt, ist die Sekunde sogar auf auf zwei Motherboards des gleichen Modells unterschiedlich lang. Diese Sekunden unterscheiden sich dann auch noch einmal von der einer (extrem genauen) Atomuhr. Dieser Unterschied wird auch Drift genannt, der bei jedem Computer unterschiedlich ist. Diesen Drift speichert der ntpd standardmässig unter /var/lib/ntp/ntp.drift und kann die Uhrzeit so auch ohne Verbindung in Netz sehr genau halten.
Mit dem Kommandozeilenprogramm ntpq kann man dem ntpd bei der Arbeit zusehen und Problemen auf den Grund gehen. Die verbundenen ntp Server werden mit dem Kommando "peers" angezeigt:
uwe@krusty ~ $ ntpq -n -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*129.70.132.33 129.70.130.70 2 u 45 64 377 65.492 4.168 0.805
+85.214.29.92 131.188.3.222 2 u 3 64 377 72.744 -0.136 0.702
+78.47.136.197 143.93.99.252 2 u 55 64 377 59.573 1.509 1.118
-92.51.130.224 85.214.71.202 3 u 60 64 377 69.906 -5.627 0.654
Hier sollte mindestens ein Server mit einem * markiert sein. Dieser ist für den ntpd am "stabilsten" zu erreichen und der eigene Referenzserver. Die mit + markierten Hosts wären die nächsten Kandidaten falls der Referenzserver nicht mehr verfügbarsein sollte. Mit "associations" kann man sich diese Beziehungen auch ansehen
uwe@krusty ~ $ ntpq -n -c associations
ind assID status conf reach auth condition last_event cnt
===========================================================
1 54760 9624 yes yes none sys.peer reachable 2
2 54761 9424 yes yes none candidat reachable 2
3 54762 9424 yes yes none candidat reachable 2
4 54763 9324 yes yes none outlyer reachable 2
Es gibt auch einen Kommandozeilenmodus von ntpq in dem man sich austoben kann:
uwe@krusty ~ $ ntpq
ntpq> ?
ntpq commands:
addvars debug lopeers passociations rl
associations delay lpassociations passwd rmvars
authenticate exit lpeers peers rv
cl help mreadlist poll showvars
clearvars host mreadvar pstatus timeout
clocklist hostnames mrl quit version
clockvar keyid mrv raw writelist
cooked keytype ntpversion readlist writevar
cv lassociations opeers readvar
ntpq>
Kommentare