• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Zeit bis ntpd anfängt zu korrigieren

Hallo,

habe in SLES9 unter vmware (WS 5.5) laufen und erhebliche Probleme mit der Systemzeit.

Nach dem Start ist zunächst die date && hwclock einigermassen synchron. Das ändert sich aber sehr schnell und die Systemzeit geht ca 60 sec/h vor. Die hwclock läuft (fast) entsprechend dem Wirt.

Also dachte ich ntp wäre optimal.

schnell mal /etc/ntp.conf configuriert
Code:
server 127.127.1.0  # local clock (LCL)
fudge 127.127.1.0  stratum 10 # LCL is unsynchronized

#driftfile /var/lib/ntp/drift/ntp.drift # path for drift file
logfile /var/log/ntp            # alternate log file

server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
und den deamon mit

Code:
 rcxntpd start

gestartet.

So dann habe ich mal (watch -n 10) nachgesehen was sich mit ntpq -p so tut
nw04saba:~ # ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) LOCAL(0) 10 l 64 64 377 0.000 0.000 0.002
20six.co.uk 172.20.20.17 3 u 6 64 377 59.943 -33313. 11061.8
20six.de 172.20.20.17 3 u 64 64 377 64.295 -23528. 6923.10
ipx10540.ipxser 192.53.103.104 2 u 57 64 377 62.017 -23875. 6974.14

auch nach stunden bleibt *LOCAL activ.

schau ich mir meine hwclock an wäre das auch OK. Nur die systemzeit bewegt sich in atemberaubendem Tempo in die Zukunft.

Die Frage ist nun.

1. Wie kann ich beschleunigen, dass ntpd die internet server nimt.

2. Wie kann man Beschleunigen, dass ntpd anfängt die Zeit zu korrigieren.

-----

Ich hatte es auch mal mit den vmware tool versucht, aber die korrigieren nicht, wenn die Zeit in die Zukunft abdriftet.

------

Ehrlich gesagt, ist das ganze fasst nicht durchschaubar, wenn man bedenkt, dass virt. Maschienen mit einem Windows System überhaupt keine Probleme habe. Nur das SLES

Linux nw04saba 2.6.5-7.191-default #1 Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386 GNU/Linu

lässt sich nicht in die zeitlichen Schranken weisen.

---

Habe eine DB laufen und da wäre es mir sehr recht wenn die Zeit stimmt.


mfg
 

sc_m

Member
Es könnte sein, dass ntpd mit dem jitter nicht zufrieden ist. Bei mir sieht die Ausgabe von "ntpq -p" so aus:
Code:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        LOCAL(0)        10 l    9   64  377    0.000    0.000   0.004
+ptbtime1.ptb.de .PTB.            1 u  451 1024  377   59.956    3.921 116.952
*rustime01.rus.u .DCFp.           1 u  394 1024  377   20.301  -13.950   0.505
+tick.Informatik 130.149.17.21    2 u  400 1024  377  135.602   37.371  24.584
Man beachte, dass dein bester Wert etwa das 14000-fache meines besten ist, die Schwankungen bei der Abfrage des Servers betragen etwa 7 Sekunden. Laut ntp-FAQ(Abschnitt 8.2.3.3) sollte einer der drei Werte unter 1000 liegen.
 
OP
B

BilboBeutlin

Newbie
Hallo,

genau das dachte ich mir auch. Ich habe bemerkt, dass ca jede Minute meine Systemzeit um ca. 2 sec angeglichen wird. Auch die HWclock stimmt auf lange Zeit nicht mit der Uhr des Wirts überein. (Ist eine vm die mir hier Probleme macht).

Beim Jitter habe ich folgendes bemerkt. Immer dann wenn "when" den "poll" Wert erreicht, wird offensichtlich neu verglichen und der Jitter wächst mit den aufgesammelten Sekunden und den sich daraus ergebeneden Differenzen. So bekomme ich tatsächlich Nie einen niedrigen Jitter.

Ich frage mich nun allerdings, warum ändet sich hwclock und Systemzeit gegenüber meiner Wirtszeit so dramatisch. (Wirt gleicht sich im übrigen - Windows mässig - sehr ordentlich ab)

viele Grüsse
 

sc_m

Member
Vielleicht würde es helfen, ein paar feste Timeserver (die nicht sehr weit entfernt stehen) anzugeben. Eine Liste findet man hier.
 

bolder

Member
Hallo!

Eine Synchronisation mit VMware-Tools funktioniert nicht. Das liegt daran, dass der Host und die VM eine unterschiedliche Kernelversion haben (ist ein Bug, aber da kommt irgendwie keine Lösung).

NTP an sich sollte funktionieren.

Auf jeden Fall darfst du nicht gleichzeitig Synchronisation über beide Verfahren machen - das geht in die Hose.
Wenn du also mit VMware-Tools probiert hast, dann ist das eventuell noch eingeschaltet. Bitte überprüfe das mal und schalte ggf. ab.

Olaf
 
OP
B

BilboBeutlin

Newbie
HAllo,

hatte zwischenzeitlich die Tools man deinstalliert - Problem hat sich aber nicht gelöst.

Mittlerweile habe ich eineüberraschende Entdeckung gemacht.

Mit eine VM mit Suse 10.0 läuft alles Problemlos selbst OHNE ntpd.

Die SLES 9 Version läuft dagegen mit 2-3sec/Min in die Zukunft.

Siehst so aus als ob Suse mit seiner Enterprise Version der Zeit voraus ist.


Jedenfalls habe ich keine Idee mehr, wie man das ganze lösen kann. Werde wohl das ganze ntpd deaktivieren und mit meiner Phantasiezeit unter Suse leben müssen.

Vielen Dank für die Tips.
 
Oben