Uhrzeit läuft aus dem Ruder

Hi,

bei meinem Motherboard (FSJ D1215) scheint die interne Zeit ein wenig zu schnell zu laufen.
Nach 3 Stunden Laufzeit des VDR, geht die interne Uhr bereits 15 Minuten vor. Das ist für Timergesteuerte Aufnahmen natürlich gift.
Mein VDR ist per W-Lan ins interne Netzwerk integriert und hat so auch Internetzugang. Ich habe bereits ntp installiert und eingerichtet, und wollte jetzt einrichten, das automatisch alle 2 Minuten die Uhrzeit mit einem Internetserver abgeglichen wird.

Ich habe diesbezüglich schon versucht den befehl "ntpdate-debian -u" per Cronjob automatisch ausführen zu lassen, was aber nicht zum gewünschten ergebnis führte. Vielleicht geht das ganze ja auch eleganter, oder ihr könnt mir meinen Fehler an meinen Zeilen im Crontab aufzeigen ... Folgende zeile habe ich eingefügt.

*/5 *   * * *   root    ntpdate-debian -u

Der befehl wird zwar laut syslog "ausgeführt" :

Jan  2 12:20:01 vdr /USR/SBIN/CRON[2892]: (root) CMD (root ntpdate-debian -u)

hat aber keinen effekt!
Gleicher Befehl direkt in der Kommadozeile, hat hingegen den richtigen Effekt :

vdr:~# ntpdate-debian -u
 2 Jan 12:18:01 ntpdate[3082]: step time server 131.234.137.24 offset -3.768804 sec

Wie automatisiere ich den befehl also auf die richtige art und weise?!

Vielen dank im voraus, für eure Hilfe!
Gruß,
Stefan

Zitat

Original von C-3PO
Ich tippe mal auf die BIOS-Batterie, wenn die leer ist, oder kurz davor, dann hat man die seltsamsten Symptome.
Ich würde das Teil mal auf Verdacht wechseln.

Good Point, selber noch nicht drauf gekommen. Werde demnächst auch mal ne neue Batterie kaufen!

Zitat

Original von geeg07

Eventuell wird ntpdate-debian nicht gefunden, crontab hat eine eigene Definition der Variable PATH.
Versuch einmal beim Aufruf den Pfad mit anzugeben also z.B. /usr/local/bin/ntpdate-debian.

wird getestet!

EDIT:

Zum einen stand in der Path Variable des Crons der Pfad zu ntpdate-debian drin, ausprobiert habe ich es aber trotzdem. auch "/usr/sbin/ntpdate-debian -u" per Crontab bringt leider keinen erfolg.

Zitat

Original von Urig
Der ntp-server besitzt eine eingebaute Drift-Korrektur. Falls du ihn bereits einsetzt, ist vielleicht die Drift falsch bestimmt worden. In dem Fall solltest du mal die /var/lib/ntp/ntp.drift löschen.

NTP läuft, und auch die .drift-file wurde angelegt. Habe sie gelöscht und den ntp-daemon neu gestartet. Mal sehen wie der Driftwert diesesmal ermittelt wird, und ob das ganze hilft.
Direkt nach dem neustarten des daemons ist die Uhrzeit übrigens auch erstmal korrekt.

Gruß,
Stefan

Wenns mal wieder länger dauert ...

Ich habe den VDR heute um

vdr:~# date 
Sa 3. Jan 11:11:08 CET 2009

angeschmissen. Direkt nach dem Starten, war die Zeit (also die obige ..) wie immer Korrekt.

Ich habe dann immer mal wieder den Tipp von Wirbel befolgt und per ntpq -p kontrolliert wann das letzt mal die Zeit synchronisiert wurde und was im drift file steht.

Um hier nicht all zuviel unrelevantes zu posten, schreibe ich euch nur das aktuellste.
Als Referenzzeit nehme ich mal mein Notebook:

$ date
Sa  3 Jan 2009 15:13:59 CET

und das ist seit 11:11 auf meinem VDR passiert:

vdr:~# ntpq -p && date && cat /var/lib/ntp/ntp.drift 
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 private.lms-con 192.53.103.104   2 u   53   64  377   50.920  -253163 4174.82
 peilfunk.de     193.79.237.14    2 u    4   64  377   51.575  -251043 4720.85
 services.127001 143.93.99.252    2 u   24   64  377   50.204  -250840 4721.87
 odin.devroot.de 192.53.103.104   2 u   58   64  377   61.153  -249900 4179.95
 tempus.zedat.fu .PPS.            1 u   46   64  377   61.971  -251908 3853.00
Sa 3. Jan 15:18:19 CET 2009
0.000

Sagen wir mal ich bin ein langsamer klicker und habe eine Sekunde gebraucht um das Terminalfenster zu wechseln, dann habe ich inzwischen also 4min 19s unterschied, und die drift-file dümpelt bei null, während mir ntp-query sagt das die letzte abfrage 4 Sekunden (wenn ich die daten richtig interpretiere ..) her ist?! Was läuft da schief? Ist das jetzt die Situation das meine Systemzeit "zuviel" von der Internetzeit abweicht und ntp sich deshalb nicht traut sie zu korrigieren?!

Vielen Dank schon jetzt für eure Hilfe!
Gruß,
Stefan

Äh, ich denke doch?!

vdr:~# tzconfig 
Your current time zone is set to Europe/Berlin
Do you want to change that? [n]: n
Your time zone will not be changed

- Ja!

Zitat

Original von e9hack
Ich würde mal behaupten, ntp hat keine Rechte die Zeit zu setzen.

Gruß
e9hack

wie überprüfe ich das?

-Kernelversion ist 2.6.24.3 wg. libcap version (habe bzw. libcap nur per locate eine .so file gefunden welche auf 1.10 endet? also v.1.10?!)

Zitat

Original von C-3PO
Poste mal bitte die Ausgabe von: [...]

vdr:~# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm 
vdr:~# cat /sys/devices/system/clocksource/clocksource0/available_clocksource           
acpi_pm pit jiffies tsc

Hi,

habe mich hier lange nicht gemeldet, weil mein Studium mir momentan wenig Zeit lässt am VDR rumzumachen.

Ich habe in der zwischenzeit schon die Batterie getauscht bin aber noch nicht weiter zum Testen gekommen.

Zitat

Original von Urig
Versuch mal den Server zu beenden, die Uhr per ntpdate zu stellen, und dann den Server neu zu starten.

Das habe ich bei den hier geposteten Ergebnisen schon öfters mal gemacht, also erst zeit per ntpdate-debian richtig gestellt (denn das funktioniert ja ...) dann den ntp-daemon neu gestartet, system länger laufen lassen, und dann diesen Thread mit den Fehlern 'penetriert'.
Leider bringt das also auch nicht den gewünschten erfolg.

Ob die sache mit der Batterie irgendwas bringt, werde ich wohl erst in einigen Tagen testen können. Habe momentan das gefühl, dass ich in der Hochschule wohne

Danke für euer Engagement!
Gruß,
Stefan