PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NTP 5 Sekunden Abweichung



pixel
30.11.08, 22:36
Hallo zusammen,

der Betreff schildert das Problem ja bereits. Ich habe einen 5-Sekunden-Unterschied zwischen meinem NTP-Server und meinem Client. Zumindest wenn die Sekunden-Anzeige des KDE's (am Client) stimmt. Nicht das mich die 5 Sekunden stören würde aber es würde mich interessieren ob das noch im Rahmen ist oder ein Fehler vorliegt. Server ist ist ein Debian 4.0-64Bit. Ist eine Xen Dom0 falls dies von Interesse ist. Die Conf am Server (192.168.0.2):

# /etc/ntp.conf, configuration for ntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
server rztime1.rz.tu-bs.de
server rztime2.rz.tu-bs.de
restrict rztime1.rz.tu-bs.de
restrict rztime2.rz.tu-bs.de
restrict 127.0.0.1
restrict 192.168.0.0 mask255.255.255.0
broadcast 192.168.0.255
restrict default ignore

Ein Test am Server:

server:~# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001
rzab0i.rz.tu-bs .INIT. 16 u - 1024 0 0.000 0.000 0.000
rzserv6i.rz.tu- .INIT. 16 u - 1024 0 0.000 0.000 0.000

sieht gut aus. Am Client (Kubuntu 8.10 - AMD64 KDE4) existiert folgende Konfiguration:

driftfile /var/lib/ntp/ntp.drift
server 192.168.0.2
und hier ebenfalls die Kontrolle:

root@bilbo:/etc/pam.d# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
[FQHN des Server] .INIT. 16 u - 1024 0 0.000 0.000 0.000
Aufgrund der Ausgaben hätte ich gesagt die Uhren laufen syncron. Wenn ich nun am Client in der KDE-Uhr die Sekunden aktiviere und per Konsole auf dem Server eingelogt 'date' aufrufe sehe ich einen Unterschied von etwa 5 Sekunden. Is das einfach nur ein KDE-Bug oder wie kann ich prüfen ob die Uhren syncron laufen?

Viele Grüße
pixel

hessijens
01.12.08, 12:13
Wie ist den die Zeit bei Debian und bei Ubuntu definiert? Könnte das an den Sprungsekunden liegen? Mehr Infos (von Openbsd) hier:

http://www.openbsd.org/faq/de/faq8.html#NTPerror

pibi
01.12.08, 15:24
Ein Test am Server:....Die sagt leider gar nichts aus, da sich das System noch nicht eingependelt hat. Ein System in Betrieb sieht etwa so aus:
remote refid st t when poll reach delay offset jitter
================================================== ============================
LOCAL(0) LOCAL(0) 10 l 55 64 377 0.000 0.000 0.015
+161.78.xx.yy 161.78.xx.yyy 4 u 154 1024 377 0.736 -1.691 12.464
*161.78.xx.yyy swisstime.ee.et 3 u 307 1024 377 0.814 3.222 3.070
+gis-raster.xxxx 161.78.xx.yyy 4 u 278 1024 377 0.798 -1.686 0.732Das "+"-Zeichen in der ersten Spalte gibt an, dass diese Source zum Synchronisieren verwendet wird. Ein "*" steht fuer einen Kandidaten zur Synchronisierung. Der Offset ist der Zeitunterschied zwischen dem lokalen Rechner und dem Sync-Server.

Weiterhin: Via NTP wird die Zeit nur in sehr kleinen Schritten nachgeregelt. Daher sollte bei jedem Start des Systems einmalig ein "ntpdate" laufen, um die Zeit grob einzustellen.

Gruss Pit.

pixel
02.12.08, 08:05
ok, am Server hat sich NTP wohl eingependelt:

server:~# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
+rzserv6i.rz.tu- 134.169.9.87 3 u 13 128 377 20.282 -1.262 0.616
192.168.0.255 .BCST. 16 u - 64 0 0.000 0.000 0.001
*rzab0i.rz.tu-bs 134.169.9.20 3 u 91 128 377 20.490 -0.040 0.158

Am Client ist die Abweichung jedoch geblieben. Nun wollte ich mit ntpdate die Zeit vom Client auf die vom Server setzen aber:

ntpdate 192.168.0.2
2 Dec 08:58:48 ntpdate[7203]: the NTP socket is in use, exiting
anscheinend funktioniert das nicht solange NTP am Client läuft. Habe den NTP am Client beendet und es nochmal probiert:

ntpdate 192.168.0.2
2 Dec 09:03:30 ntpdate[7260]: no server suitable for synchronization found
Warum ist der Client der Meinung das der Server keine brauchbare Zeit hat?

Viele Grüße
pixel

pibi
02.12.08, 10:19
ok, am Server hat sich NTP wohl eingependelt:Das sieht schon mal nicht schlecht aus. Und wie sieht der Output aus, wenn Du diesen Befehl auf dem Client aufrufst?
anscheinend funktioniert das nicht solange NTP am Client läuftSo iss das;-)
Warum ist der Client der Meinung das der Server keine brauchbare Zeit hat?Das gilt es herauszufinden. Dann wundert es micht nicht, dass der Client die Zeit nicht angesagt bekommt. Erlaubt denn Dein Server 192.168.0.2 ueberhaupt Connects von Clients? Evtl. Firewall?

Gruss Pit.

pixel
04.12.08, 10:25
Das sieht schon mal nicht schlecht aus. Und wie sieht der Output aus, wenn Du diesen Befehl auf dem Client aufrufst?


root@bilbo:/home/sven# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
[FQHN of 192.168.0.2] .INIT. 16 u - 1024 0 0.000 0.000 0.000


Das gilt es herauszufinden. Dann wundert es micht nicht, dass der Client die Zeit nicht angesagt bekommt. Erlaubt denn Dein Server 192.168.0.2 ueberhaupt Connects von Clients? Evtl. Firewall?
Auf dem Server läuft keine Firewall und aufgrund der ntp.conf auf dem Server sollte das ja passen, oder?