Arch Linux

Uhr läuft langsam .. oder doch 2 Probleme?

zico

Hallo Freunde

Schon früher (mit nem anderen PC) habe ich festgestellt, dass meine BIOS Uhr immer etwas hinterherhinkt. Dahe rhabe ich schon früh auf ntpd umgestellt, was das Problem löst.

Durch einen Providerwechsel war ich nun geschlagene 2 Wochen offline. Währenddessen habe ich das Problem mal etwas beobachten können.

Ergebnis: Nach 14 Tagen lag meine BIOS Uhr geschlagene 45 Minuten zurück. Ich glaub doch, dass das etwas viel ist. Rumgegoogelt hab ich ein wenig, doch meist das Problem im Zusammenhang mit VMs gefunden, was bei mir jedoch nicht zutrifft.
Wie schon gesagt ist durch ntpd das Problem nicht wirklich schlimm, doch möchte ich wissen, woher das kommt und was ich dadgegen tun kann (FALLS nicht das Mainboard direkt schuldig ist).

Nun habe ich mal die dmesg durchforstet und eins gefunden, was ich aber nicht direkt zuordnen kann, aber mich auch interessiert und vllt hängt beides zusammen:

Clocksource tsc unstable (delta = -295533731 ns)

Also falls irgendwer irgendwelche Ideen hat, einfach raus damit, ich würde mich über hjede Hilfe sehr freuen.

ZaphodX

Da fallen mir zwei Sachen ein:

1. in der rc.conf HARDWARECLOCK von "UTC" auf "localtime" ändern oder umgekehrt (insbesondere wenn du noch Windoof mit nutzt).

oder

2. ne neue Lithium(?)-Batterie fürs Motherboard kaufen.

SaThaRiel

zico schrieb

Clocksource tsc unstable (delta = -295533731 ns)

Wenn mich nicht alles täuscht, kommt diese Meldung vom ntpd.
Zu Deinem Problem kann man eigentlich nur eins sagen: Es ist eigentlich keins. Die meisten Boarduhren gehen eher an die Decke als richtig. Das sind eben keine schweizer Präzisionsuhren 😉 Mit ntp bist Du auf jeden Fall gut beraten.
Die Batterie tauschen könnte zumindest eine Besserung bringen, aber wird das Problem nicht lösen.

ZaphodX

...oder sich regelmäßig beim Einloggen/Booten/mit crond mit ner Atomuhr syncen; müsste doch rauszufinden sein, wie das geht.

zico

Okay also den Tipp mit der rc.conf versuche ich mal.

Dass das ganze generell am Mainboard liegt finde ich schwer zu glauben... wenn dann muss mein Mainboard speziell einfach sch...limm sein.
Meine Freundin nutzt windows auf dem Laptop. Dort is die Uhr nicht SO derb aus der Reihe gelaufen... Müsste das jetzt mal mit meinem eigenen Windows gegenchecken....

ZaphodX

zico schriebSchon früher (mit nem anderen PC) habe ich festgestellt, dass meine BIOS Uhr immer etwas hinterherhinkt.

Hmm... also meinst du jetzt wirklich die BIOS-Uhr (also die Uhr, wenn du im BIOS bist), oder hälst du das für die BIOS-Uhr, was du auf dem Desktop/im Termnal mit date siehst?

Und, also hast du jetzt tatsächlich noch Windows parallel laufen?

Außerdem kommt es schon mal vor, dass Motherboard-Batterien mal nachlassen und leer werden, wenn es auch recht selten ist (z.B. bei älteren PCs).

BioHazard

Ziehst du zufällig den Stecker raus oder schaltest das Netzteil deines Rechners ab, wenn du ihn nicht benutzt, oder ist dein Rechner schon recht alt ?
45min innerhalb von 2 Wochen sind schon sehr heftig, aber nicht unrealistisch. Bei einer schwachen BIOS-Batterie (weil durch fehlende Netz-Spannung stark beansprucht, alt, etc.) ist das durchaus möglich. Eine ganz leere Batterie begrüßt dich nach jedem Verlust der Netzspannung mit der default-Zeit bei Auslieferung und der Aufforderung, BIOS-Einstellungen zu setzen 😉
Dass das Notebook deiner Freundin präziser ist, liegt vermutlich daran, dass es durch den Akku (der ja nie ganz leer ist und auch nicht sein darf) permanent eine Stromquelle hat (ist deutlich stabiler, da die Spannung konstant gehalten wird). Mit dem Betriebssystem hat die Genauigkeit der Systemzeit übrigens nichts zu tun. Nimmt deine Freundin den Akku aus dem Notebook, ohne es am Netz zu belassen, wird auch die Batterie ihres Notebooks irgendwann schwächer und die Systemzeit ungenauer.

Das TSC (TimeStamp Counter) unstable ist, ist eigentlich nicht weiter schlimm. In Mehrprozessorsystemen/Verteilten Systemen ist manchmal sogar der Sinn umstritten, da diese alle TSCs synchron halten müssen. Man versucht durch constant_tsc das Problem zu lösen, aber ich hab noch kein Multiprozessorsystem mit linux gesehen, bei denen TSC als stabil erkannt wurde (zumindest nicht, wenn sie über dynamische Taktraten und Powerstates verfügen). In der Regel wird stattdessen ACPI oder HPET genutzt. Die Systemzeit hängt davon auch nicht unbedingt ab. (es geht hierbei mehr um eine sehr genaue chronologie von ereignissen im laufenden Betrieb)

In der rc.conf die Zeitzone zu ändern bringt dir nichts. Es wird halt dann entweder die UTC-Zeit gespeichert und gemäß der Zeitzone umgerechnet, oder direkt die Lokalzeit. Auswirkungen auf die Hardware (die hier das Problem ist) hat das nicht.

Ich halte eine schwächelnde BIOS-Batterie anhand deiner Beschreibung für die wahrscheinlichste Ursache. Sollte das zutreffen, bekämpfst du mit ntpd nur das Symptom 😉

zico

Hmm diese Argumentation kingt schlüssig, aber da gibts einige Bedenken hier:

1) Das Notebook läuft ohne Akku, sondern nur am Netzteil als "PC-Ersatz"
2) Das Notebook ist bereits viel älter als mein PC
3) Der PC ist noch kein halbes Jahr alt - das Mainboards auch nicht

Vielleicht ist die Batterie auch kaputt, obwohl ich beschwören könnte, das Problem auch schon öfters gesehen zu haben... hmm...

SaThaRiel

Nur mal so als kleines Schmankerl: Ich hab auch schon Server (SUN in dem Fall) gesehen, die frisch aus der Verpackung gekommen sind und eine Abweichung der Uhr von ~10 Minuten in einer Stunde hatten. Die Hardwareuhren sind nunmal wirklich nicht geeicht, auch, wenn dieser spezielle Fall sehr heftig war, kommt es vor.
ntpd ist immer die beste Wahl - gibt ja auch sowas bei Windows.

eyesky

Meine Uhr hatte mich auch bis eben noch genervt .....
also
Uhr und Datum Atomgenau ...

pacman -S ntp
ntpdate als daemon laufen lassen in

/etc/rc.conf
DAEMONS=( ntpdate ........
ebenso pruefen ob:

HARDWARECLOCK="localtime"
USEDIRECTISA="yes"
TIMEZONE="Europe/Berlin"
KEYMAP="de-latin1-nodeadkeys"
CONSOLEFONT="default8x16"
CONSOLEMAP=
USECOLOR="yes"

gesetzt ist ...
sowie wenn noetig in /etc/ntp.conf z.B. setzen server 1.de.pool.ntp.org

.....
die ca. 50Herz Abteilung aus der Steckdose laesst den besten Pc mit Uhrzeit immer blass aussehen
behaupte ich mal ! 😃

gefunden in
https://forum.archlinux.de/?page=Postings;id=20;thread=7151

lg e.s.

zico

Okay also ich bin jetzt von ntpdate über cron auf openntpd als daemon umgestiegen um die Uhrzeit etwas sanfter zu korrigieren. Sonst springen mir einige Programme zu hart rum, wen ntpdate aktiv wird.

Alles soweit so gut:

HARDWARECLOCK="localtime"

in rc.conf

ebenso wie:

DAEMONS=(syslog-ng acpid cpudyn network dbus hal fam netfs crond samba openntpd)

und in meiner ntpd.conf

servers de.pool.ntp.org

Jetzt bin ich total baff:
Nach einigen Tagen Uptime, wird die Uhr WIEDER unsyncron, OBWOHL der ntpd Prozess LÄUFT!!! (ja und ne Internetverbindung gibbet auch)

Ich fang bald an zu heulen... denn das ganze müsste doch IRGENDWIE funktionieren...
Da mein Rechner mehrere Tage läuft bringt es mir nichtmal etwas, nur beim Systemstart die Zeit zu setzen, da nach schon einem Tag 3-5 Minuten verschwinden... Anscheinend EGAL ob mit oder ohne openntpd...

EDIT: Das hier ist der auzug aus der daemons.log:

ec  9 11:47:57 stella ntpd[14058]: adjusting local clock by 0.167774s
Dec  9 11:55:44 stella ntpd[14058]: adjusting local clock by 0.903394s
Dec  9 12:00:14 stella ntpd[14058]: adjusting local clock by 1.301300s
Dec  9 12:02:48 stella ntpd[14058]: adjusting local clock by 1.813040s
Dec  9 12:06:56 stella ntpd[14058]: adjusting local clock by 2.179159s

Das Offset wird immer größer. Offensichtlich wird die Uhr in meinem System nicht nachgestellt... wtf.

EDIT2:
Wie im Log ja zu lesen ist, verliere ich ca. 1 Sekunde innerhalb von 5 Minuten. Um das Problem einzugrenzen hab ich meine Funkuhr neben den Bildschirm gestellt, BIOS aufgerufen und es EXAKT angeglichen.
Die BIOS Uhr is gute 10 Minuten 100% syncron zur Funkuhr gelaufen, ohne auch nur ne halbe Sekunde zu verlieren....
Ich sag jetzt mal als unbedarfter Nutzer: AM BIOS LIEGTS NICH!

GerBra

Was ist das für ein Rechner? CPU, Mehrkern?
WIe schaust du nach der Zeit?
date zeigt die Systemzeit an, so wie Linux die Zeit in eigenen Timern verwaltet.
hwclock zeigt die BIOS-Uhr an.

Ist bei dir im BIOS eine Option HPET?
Was zeigen denn:
dmesg | grep rtc
dmesg |grep hpet

zico

Okay also der Rechner ist ein AMD A64 6000+ (DUALCORE)

Die Zeit im BIOS hab ich einfach nach meiner Funkuhr nun gestellt und sie wie gesagt 10 Minuten lang verglichen.

Das ganze Problem merke ich eigentlich ja nur, dass nach ca 1-2 Tagen meine Uhr, in meiner XFCE Taskbar komplett hinterherhinkt und die Nachrichten in daemons.log ein immer größeres Offset zeigen.

Nach 12 Minuten Uptime meines Rechners (mit laufendem ntpdate):

bash-3.2# date ; hwclock
Tue Dec  9 12:50:04 CET 2008
Tue 09 Dec 2008 12:50:06 PM CET  -0.073155 seconds

Habe kurz vorher hpet=disable als Kerneloption gesetzt... wurde mir ausserhalb als Tipp gegeben. Jetzt rennt acpi_pm als clocksource.

Geforderte Ausgaben:

bash-3.2# dmesg | grep rtc
rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month
bash-3.2# dmesg | grep hpet
Command line: root=/dev/sda2 ro vga=775 nopat hpet=disable
Kernel command line: root=/dev/sda2 ro vga=775 nopat hpet=disable

Dennoch - ntpd produziert imer größere Offsets - auch mit acpi_pm:

Dec  9 12:39:34 stella ntpd[4141]: adjusting local clock by 6.009722s
Dec  9 12:43:44 stella ntpd[4141]: adjusting local clock by 6.192063s
Dec  9 12:48:02 stella ntpd[4141]: adjusting local clock by 6.946649s
Dec  9 12:51:19 stella ntpd[4141]: adjusting local clock by 7.409925s

Hier mal meine ganze ntpd.conf:

# $OpenBSD: ntpd.conf,v 1.7 2004/07/20 17:38:35 henning Exp $
# sample ntpd configuration file, see ntpd.conf(5)

# Addresses to listen on (ntpd does not listen by default)
listen on *
#listen on 127.0.0.1
#listen on ::1

# sync to a single server
#server ntp.example.org
#server time.fu-berlin.de

# use a random selection of 8 public stratum 2 servers
# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
servers pool.ntp.org

Dirk

zico schrieb Nach 14 Tagen lag meine BIOS Uhr geschlagene 45 Minuten zurück.

BIOS-Batterie leer?

zico

die BIOS Uhr rennt korrekt. Im AUSGESCHALTETEN Zustand oder direkt im BIOS rennt das System sogar viel besser in der Zeit als während der Uptime in Linux.

Wenn ich "date" regelmäßig anschau, kann ich innerhalb WENIGER MINUTEN sehen, wie die Ausgabe von meiner Funkuhr (oder meiner Wanduhr, meinem Videotext, meiner Uhr im Wii oder meiner PS3, etc etc) abweicht, während hwclock da viel genauer läuft.

Und es hat den Anschein, als könnte ntp das nicht mehr korrigieren. Mich interessiert mittlerweile auch vielmehr, WARUM das so ist - ich will nicht nur mit ntpd das Symptom bekämpfen.

GerBra

Und stimmt die "falsche Uhrteit" aus dem xfce-Tool denn mit dem überein was date sagt?
Diese xfce-Uhr startet ja evtl. nur einen eigenen Timer, muß also nicht die Kernel-Zeit darstellen.

openntp scheint ja etwas zu korrigieren (diese Korrekturen an der Systemzeit scheinen ja aber nicht
zu deiner xfce-Uhr durchzudringen). Außerdem legen die ntp-Daemons nach einiger Zeit ein driftfile
an, in dem berechnete bzw. zu erwartende Abweichungen drinstehen. Wenn dein driftfile (ntp legt
das nach /varlib/ntp ab, openntp weiß ich nicht) Werte aus einem alten Lauf hat (wo die Abweichungen
noch größer war), dann wird evtl. versucht eine angenommene zu große Drift zu korrigieren.
Also openntp mal stoppen, wenn vorhanden das driftfile löschen und wieder starten.

Ich würde mal folgendes machen:
starte ein Terminal und laß dort mal laufen:
watch --interval 30 "date ; hwclock"
Das zeigt dir alle 30s die Ausgaben von date(Systemzeit) und hwclock(BIOS-Uhr) an.
a) driften diese jetzt (egal ob mit oder ohne ntpd) mit der Zeit voneinander ab?
b) Driften einer oder beide von der "Wanduhr/Atomuhr" ab?
c) Stimmt deine xfce-Uhr mit der date-Ausgabe von oben überein?

zico

Vor meinem vorletzten Post hab ich genau das gecheckt und bin auch Zeile für Zeile vom Archlinux.org-WIKI nach ntpd umgestiegen. Ich hab nun wieder ne uptime von 20 minuten.
DATE: Tue Dec 9 13:41:31 CET 2008
HWCLOCK: Tue 09 Dec 2008 01:41:36 PM CET -0.913150 seconds (entspricht meiner Funkuhr)
Hab also wieder ne Differenz/einen Verlust von ca. 4 Sekunden auf der Systemzeit.

Komischerweise:

[zico@stella ~]$ cat /var/lib/ntp/ntp.drift 
0.000

GerBra

Hmm, gibt es das selbe Bild wenn du ohne ntpd startest? ntp "pfuscht" ja ständig an der Systemzeit
rum wenn diese falsch geht (und scheint die notwendigen Korrekturen ja nicht auszuführen)

Ich vermute weiterhin schlechtes BIOS bzw. schlechtes Motherboard.
Ist das der aktuelle Arch-Kernel?
Was sagen denn:
zless /proc/config.gz | grep HZ

Zum hpet nochmal: HPET ist ja der genauere Timer und auch für SMP-Systeme ausgelegt. hpet hast
du nun ja disabled per kernel-Parameter. Hast du in deinem BIOS denn Hinweise das HPET überhaupt
vorhanden ist. Bzw. tauchen Meldungen in dmesg zu hpet auf wenn du ohne hpet=off startest?

Weiterhin können AFAIK auch falsche Tick-Werte (die Hz-Werte von oben) diese Abweichungen
verursachen. Ich habe zumindest Postings gelesen das manche Kombinationen von BIOS/Mainboard
und CPUs nur vernünftig arbeiten wenn diese Ticks auf 100Mz gesetzt sind.
Wenn du den Arch-Kernel verwendest könntest du auch nochmal probieren:
a) als kernelparameter nohz=off
b) als kernelparameter nolapic
b) einen Kernel bauen mit CONFIG_HZ_100 statt CONFIG_HZ_300

Aber immer nur eine Sache testen (hpet oder nohz, nie mehrere Sachen auf einmal).
Und wie gesagt: bei allen Tests würde ich sowohl ntpd als auch ntpdate nicht starten lassen.

zico

Hmm, gibt es das selbe Bild wenn du ohne ntpd startest? ntp "pfuscht" ja ständig an der Systemzeit
rum wenn diese falsch geht (und scheint die notwendigen Korrekturen ja nicht auszuführen)

Japp er geht auch so falsch. So flasch, dass es das maximale Offset, welches openntpd korrigieren KANN, übersteigt.
ntpd selbst hat in meinen vorherigen Tests alle 5 Minuten ca. 2,5 Sekunden an der Systemzeit rumgeschraubt. Das wäre ja okay, aber einige anwendungen geraten bei solchen Werten natürlich heftig ins Stolpern.

Ich vermute weiterhin schlechtes BIOS bzw. schlechtes Motherboard.

Da stößt mein technisches Verständnis an seine Grenzen. Zum einen da hwclock ja wunderbar läuft und auch Windows XP keine solchen Abweichungen zeigt (und nein, es kann die Uhr nicht syncen, da mein Windows NIRGENDWO hin telefonieren darf, keine Netzwerktreiber).

Was sagen denn:
zless /proc/config.gz | grep HZ

<b>CONFIG_NO_HZ=y</b>
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_MACHZ_WDT=m

Komisch. Sieht so aus als wäre der Kernel schon OHNE HZ gebaut?

Bzw. tauchen Meldungen in dmesg zu hpet auf wenn du ohne hpet=off startest?

ACPI: HPET 7FEE7680, 0038 (r1 GBT    GBTUACPI 42302E31 GBTU       98)
ACPI: HPET id: 0x10b9a201 base: 0xfed00000
hpet clockevent registered
rtc0: alarms up to one month, hpet irqs

hpet=no/disabled hab ich ja nun schon getestet, weswegen acpi_pm zum Einsatz kam. Hat leider auch nix gebracht. Also mir bleibt nur noch die HZ Geschichte.

GerBra

Teste auch nochmal die anderen genannten kernelparameter, also v.a.:
nohz=off
und nolapic

Diese CONFIG_NO_HZ=y Einstellung ist v.a. für Notebooks interessant, da ein tickless Kernel
besser Strom sparen können soll. Mit obigem Parameter schaltest du das tickless aus.

Es müßte schon etwas mit deinem Bios/Board zu tun haben, bei einem generellen Kernel-Bug o.ä.
hätten wir ja viel öfters das Problem (ich habe driftende Uhrzeiten seit Kernel 2.4 nicht mehr
in meinen Umgebungen gesehen, und da v.a. bei SMP-Systemen).

Schau auch nochmal, ob du in deinem BIOS zu HPET etwas einstellen kannst. Ich las vorhin mal in
einem Posting das jemand etwas von 32 auf 64 umstellen konnte (oder umgekehrt) und das half
ihm. Bin mir aber da auch nicht ganz sicher...

Nächste Seite »