# "Eingeschlafene" Uhr

## Raze

Ich habe hier auf einem System ein recht seltsames Szenario.

Die Uhrzeit verliert pro ca. 20 Sekunden eine Sekunde, was in dem Fall leider absolut fatal ist.

```
# /etc/conf.d/clock

# Set CLOCK to "UTC" if your system clock is set to UTC (also known as

# Greenwich Mean Time).  If your clock is set to the local time, then

# set CLOCK to "local".  Note that if you dual boot with Windows, then

# you should set it to "local".

CLOCK="UTC"

# Select the proper timezone.  For valid values, peek inside of the

# /usr/share/zoneinfo/ directory.  For example, some common values are

# "America/New_York" or "EST5EDT" or "Europe/Berlin".  If you want to

# manage /etc/localtime yourself, set this to "".

TIMEZONE="Europe/Berlin"

# If you wish to pass any other arguments to hwclock during bootup,

# you may do so here.

CLOCK_OPTS=""

# If you want to set the Hardware Clock to the current System Time

# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="yes"

### ALPHA SPECIFIC OPTIONS ###

# If your alpha uses the SRM console, set this to "yes".

SRM="no"

# If your alpha uses the ARC console, set this to "yes".

ARC="no"
```

Alle 15 Minuten wird derzeit mit einem Zeitserver per ntpdate synchronisiert, allerdings ist die auftretende Differenz bis dahin schon enorm.

```
ntpdate ntp.server; date; sleep 10; date; ntpdate ntp.server

25 Aug 11:44:47 ntpdate[18355]: step time server 87.237.120.2 offset 1.162599 sec

Tue Aug 25 11:44:47 CEST 2009

Tue Aug 25 11:44:57 CEST 2009

25 Aug 11:44:57 ntpdate[18359]: adjust time server 87.237.120.2 offset 0.490815 sec
```

```
time sleep 10

real    0m10.005s

user    0m0.000s

sys     0m0.000s
```

Zweiteres wundert mich ein wenig, denn der sleep läuft problemlos ..

/etc/localtime ist wie die Timezone in der clock.conf auf Europe/Berlin eingestellt.

€:

Das System läuft 24/7/365 und die Uhrzeit wird somit nicht häufiger mit der HW-Clock überschrieben.

----------

## mrsteven

Der Übeltäter könnte die Datei /etc/adjtime sein. Verschiebe die mal irgendwo anders hin und schau ob das hilft.

----------

## Raze

```
mv /etc/adjtime /etc/adjtime.back

ntpdate ntp.server; date; sleep 10; date; ntp.server

25 Aug 13:54:54 ntpdate[19360]: step time server 87.237.120.2 offset 27.428373 sec

Tue Aug 25 13:54:54 CEST 2009

Tue Aug 25 13:55:04 CEST 2009

25 Aug 13:55:05 ntpdate[19364]: step time server 87.237.120.2 offset 0.527499 sec
```

Leider nicht  :Sad: 

Noch eine weitere Idee?

€:

```
/etc/init.d/clock restart

 * WARNING:  you are stopping a boot service.

 * Stopping syslog-ng ...                                                                                                                              [ ok ]

 * Setting hardware clock using the system clock [UTC] ...                                                                                             [ ok ]

 * Setting system clock using the hardware clock [UTC] ...                                                                                             [ ok ]

 * Starting syslog-ng ...                                                                                                                              [ ok ]

cat /etc/adjtime

0.000000 1251201545 0.000000

1251201545

UTC

cat /etc/adjtime.back

1.012686 1251192525 0.000000

1251192525

UTC

ntpdate ntp.server; date; sleep 10; date; ntpdate ntp.server

25 Aug 13:59:31 ntpdate[19540]: step time server 87.237.120.2 offset 13.223447 sec

Tue Aug 25 13:59:31 CEST 2009

Tue Aug 25 13:59:41 CEST 2009

25 Aug 13:59:41 ntpdate[19544]: step time server 87.237.120.2 offset 0.529886 sec
```

Bringt leider auch nichts.

----------

## mrsteven

Bin gerade auch etwas ratlos. Im Kernel-Log findet sich nichts? Was für eine Maschine ist das denn?

Eventuell kann es helfen einen anderen Zeitgeber auszuwählen. In /sys/devices/system/clocksource/clocksource0/current_clocksource steht welcher gerade aktiv ist, die Datei available_clocksource im selben Verzeichnis listet die Möglichkeiten auf.

Beim Booten kannst du dann über einen Kernelparameter bestimmen welchen Zeitgeber du benutzen willst, also z.B: clocksource=acpi_pm.

----------

## Raze

Hm, im dmesg macht mich etwas stutzig

```

Clocksource tsc unstable (delta = 63947129 ns)

Time: jiffies clocksource has been installed.

```

Ich bin aber auch nicht so sehr damit vertraut, dass ich mit der Meldung was anfangen kann. An sich ist dass das erste System unter hunderten, welches solche Probleme bei der Uhrzeit macht.

```
cat /sys/devices/system/clocksource/clocksource0/current_clocksource

jiffies
```

```
 cat /sys/devices/system/clocksource/clocksource0/available_clocksource

jiffies tsc
```

```
uname -a

Linux 2.6.23-gentoo-r8 #1 SMP Sat Feb 16 01:19:39 CET 2008 i686 Intel(R) Xeon(R) CPU E5320 @ 1.86GHz GenuineIntel GNU/Linux
```

----------

## toralf

Ich mache mit HPET gute Erfahrungen :

```
tfoerste@n22 ~ $ zgrep HPET /proc/config.gz

CONFIG_HPET_TIMER=y

CONFIG_HPET=y

CONFIG_HPET_MMAP=y

tfoerste@n22 ~ $ dmesg | grep clock

hpet clockevent registered

```

----------

## Raze

Ist im Kernel leider nicht drin, neuer Kernel & reboot leider keine Option.

----------

## theotherjoe

ich denke ein ntp server koennte helfen die uhrendrift

zu kompensieren.

```
net-misc/openntpd

net-misc/ntp
```

ich bevorzuge den openntpd, finde der ist einfacher zu handhaben.

----------

## toralf

ntp ist auf jden Fall empfehlenswert, aber eine Ungenauigkeit von 3% ist schon echt heftig.

----------

## Raze

Auch mit laufendem ntpd schläft die Uhr ein ..

Blöderweise läuft dort auch noch eine sehr zeitkritische Applikation, bei der 3 Sekunde am Tag gerade so tolerabel wären .. aber nicht in knapp einer Minute  :Sad: 

Edit:

Während dem Schreiben des Beitrages gingen 5 Sekunden "verloren".  :Shocked: 

----------

## Erdie

 *Raze wrote:*   

> Hm, im dmesg macht mich etwas stutzig
> 
> ```
> 
> Clocksource tsc unstable (delta = 63947129 ns)
> ...

 

Diese Meldung habe ich auch ohne dass etwas falsch läuft. Es muß demnach nicht unbedingt mit dem Problem zu tun haben.

-Erdie

----------

## Raze

```
/usr/sbin/ntpdate ntp.server && hwclock --systohc && mv /etc/adjtime /etc/adjtime.back
```

Eine Minute später sind es schon wieder 5 Sekunden, die die Uhr abweicht. Derweil bin ich völlig ratlos.

----------

## Wolle

 *Raze wrote:*   

> 
> 
> ```
> mv /etc/adjtime /etc/adjtime.back
> ```
> ...

 

Ich würde der /etc/adjtime nochmal ne Chance geben und sie nicht aus dem laufenden System, sondern von einer Boot-CD (z.B. Installations-CD) aus löschen. Ich habe schon öfters das Problem gehabt, dass es aus dem laufenden System keinen Effekt hat. Ich vermute, die Datei wird beim runterfahren wieder mit ihren falschen Werten geschrieben.

Du kannst die /etc/adjtime ruhig löschen. Da steht nur drin um wieviel deine Uhr falsch läuft, damit das korrigiert werden kann. Wenn die Datei nicht existiert, wird die Uhr von Linux einfach laufen gelassen. Wenn du die Uhr stellst, wird die /etc/adjtime wieder angelegt.

----------

## Raze

Ich hatte noch ein paar Dinge heute mittag ausprobiert gehabt, Zeit über hwclock neu setzen, von --hctosys, /etc/adjtime wird dann neu angelegt.

Aber alles zwecklos, nach ein paar Minuten sinds schon mehr als 15 Sekunden. Atm rennt

```

#!/bin/bash

while true;

do

sleep 20

ntpdate ntp.server &> /dev/null

done

```

 :Rolling Eyes: 

Ich wußte mir schlicht nicht mehr zu helfen, eine wirkliche Dauerlösung ist das natürlich nicht. Daher ist jeder Ansatz (der nichts mit rebooten zu tun hat  :Wink:  ) willkommen.

----------

## 69719

Mach des mal, aber auch mal ein paar Tage warten...

http://de.linwiki.org/wiki/Linuxfibel_-_System-Administration_-_Zeit_und_Steuerung#Die_Datei_.2Fetc.2Fadjtime

----------

## theotherjoe

raze, hast du schon mal nachgesehen ob die zeitdrift annaeherend

konstant ist oder zb. von der last abhaengt?

----------

## Raze

@escor:

Mit dem hwclock --adjust hatte ich bereits gearbeitet, leider sinds eben keine 12 Sekunden in 2 Wochen sondern eher 5 Minuten.

Die Last auf dem System ist relativ konstant zwischen 0,6 und 1.

```
cat /proc/loadavg

0.75 0.80 0.90 1/165 13528
```

Ich habe gerade mal

```

sleep 30; ntpdate ntp.server; sleep 30 ...

```

ausgeführt, bis auf den ersten Zeitsync ist die Differenz immer annähernd gleich, zwischen den Aufrufen lief eben 2 Minuten kein Abgleich.

```

26 Aug 11:08:06 ntpdate[13431]: step time server 87.237.120.2 offset 3.486154 sec

26 Aug 11:08:38 ntpdate[13433]: step time server 87.237.120.2 offset 1.592612 sec

26 Aug 11:09:10 ntpdate[13435]: step time server 87.237.120.2 offset 1.573352 sec

26 Aug 11:09:41 ntpdate[13440]: step time server 87.237.120.2 offset 1.588355 sec

26 Aug 11:10:13 ntpdate[13498]: step time server 87.237.120.2 offset 1.576720 sec

26 Aug 11:10:45 ntpdate[13501]: step time server 87.237.120.2 offset 1.598388 sec

26 Aug 11:11:16 ntpdate[13503]: step time server 87.237.120.2 offset 1.498191 sec

26 Aug 11:11:48 ntpdate[13505]: step time server 87.237.120.2 offset 1.563701 sec

```

```

26 Aug 11:13:08 ntpdate[13508]: step time server 87.237.120.2 offset 3.953110 sec

26 Aug 11:13:39 ntpdate[13511]: step time server 87.237.120.2 offset 1.568615 sec

26 Aug 11:14:11 ntpdate[13513]: step time server 87.237.120.2 offset 1.576487 sec

26 Aug 11:14:43 ntpdate[13515]: step time server 87.237.120.2 offset 1.579341 sec

26 Aug 11:15:14 ntpdate[13517]: step time server 87.237.120.2 offset 1.549566 sec

26 Aug 11:15:46 ntpdate[13520]: step time server 87.237.120.2 offset 1.590533 sec

26 Aug 11:16:18 ntpdate[13522]: step time server 87.237.120.2 offset 1.610528 sec

26 Aug 11:16:49 ntpdate[13525]: step time server 87.237.120.2 offset 1.574054 sec

```

----------

## 69719

Hast du dich auch ein paar Tage oder ein paar Minuten um deine Familie gekümmert?   :Very Happy: 

 *Raze wrote:*   

> @escor:
> 
> Mit dem hwclock --adjust hatte ich bereits gearbeitet, leider sinds eben keine 12 Sekunden in 2 Wochen sondern eher 5 Minuten.
> 
> 

 

Du kannst auch mal http://www.informatikserver.at/LHB/node149.html#SECTION00640300000000000000 versuchen.

----------

## Knieper

Ohne das Thema komplett zu lesen - die Batterie ist noch voll?

----------

## Raze

Mal einen auf ganz blöd gemacht .. was hat die massiv von der Hardwareuhr abweichende Softwareuhr mit ner möglicherweise leeren Batterie zu tun?

Ich hatte auch schon mehrfach leere Batterien, allerdings macht dass dann einmal Probleme in Form verlorener Bios-Einstellungen, aber dass die Softwareclock ne Abweichung von 1,5 Sekunden pro 30 Sekunden hat würde ich damit nicht in Verbindung bringen.

Mehrere Versuche mit hwclock --adjust die /etc/adjtime neu zu schreiben waren leider erfolglos. Ich kann leider auch schlecht mehrfach die Uhrzeit um ein paar Minuten "weglaufen" lassen, da dies die Applikation des Kunden beeinträchtigt. Dämliche Situation  :Sad: 

----------

## 69719

Hast du mal am "Timer frequency" in Kernel geschraubt? Vielleicht hat dies ja eine Auswirkung darauf.

----------

## Josef.95

Ich würde den Vorschlag von "mrsteven" noch mal versuchen.., also in deinem Fall

"clocksource=tsc"

an die Kernel Zeile anhängen.

(ist aber leider mit einem reboot verbunden)

----------

## misterjack

 *theotherjoe wrote:*   

> ich denke ein ntp server koennte helfen die uhrendrift
> 
> zu kompensieren.
> 
> ```
> ...

 

Und öffnet nicht einen Port.

----------

## mrsteven

Na ja, an sich hat es auch seine Gründe, wieso der TSC als Zeitquelle unter Umständen instabil sein kann: Die C-States, welche aktiviert werden, wenn der Prozessor nichts zu tun hat um Strom zu sparen; oder eine CPU mit dynamischer Taktung... Wenn das so im Log steht, dann wird das wahrscheinlich schon seine Richtigkeit haben.

Um mal nicht komplett ins leere zu raten: Kannst du mal mit einer Stoppuhr messen, ob das Ergebnis von deinem time sleep (am besten mit größerer Zeitspanne) wirklich stimmt? Wenn ja, kannst du immerhin meinen Vorschlag von vorhin schon mal ausschließen...  :Wink: 

----------

## ChrisJumper

Hey Raze,

kann es sein das deine OS als Gast-Betriebssystem in einer Virtuellen Umgebung läuft?

Grüße

----------

## Knieper

 *Raze wrote:*   

> was hat die massiv von der Hardwareuhr abweichende Softwareuhr mit ner möglicherweise leeren Batterie zu tun?

 

Meine HW-Uhr wurde kurz vorm Batterietot langsamer - gab dann lustige Effekte mit der SW-Uhr die zum Abgleich immer einen Sprung in die Vergangenheit machte. Aber wie gesagt, ich habe das Thema nicht gelesen.

----------

## Raze

 *escor wrote:*   

> Hast du mal am "Timer frequency" in Kernel geschraubt? Vielleicht hat dies ja eine Auswirkung darauf.

 

Nein, da reboots zum "blind testen" wie gesagt keine Möglichkeit sind.

 *Quote:*   

> Die C-States, welche aktiviert werden, wenn der Prozessor nichts zu tun hat um Strom zu sparen; oder eine CPU mit dynamischer Taktung

 

Der Kernel hat keinerlei Stromsparfunktionen inklusive.

 *Quote:*   

> Um mal nicht komplett ins leere zu raten: Kannst du mal mit einer Stoppuhr messen, ob das Ergebnis von deinem time sleep (am besten mit größerer Zeitspanne) wirklich stimmt?

 

Werd ich machen.

 *Quote:*   

> kann es sein das deine OS als Gast-Betriebssystem in einer Virtuellen Umgebung läuft? 

 

Nein.

----------

