System-/Softwareuhr extrem ungenau.

[ZOiD]

Hallo zusammen,
ich habe 2 nagelneue Rechner als fileserver eingerichtet. (smb, ftp)
Bei beiden Rechnern habe ich allerdings das Problem, dass die Systemuhr von linux extrem ungenau geht, wenn ich ´nen stündlichen cron-job mache, sind das 8+ sek. pro Stunde!
Ich habe auch mal alles "zurückgesetzt", also einfach das driftfile gelöscht, bios uhr eingestellt, neustart, warten. Am nächsten Tag ist die Differenz wieder so gross, dass Prozesse sich sicherheitshalber beenden...
Ich werde natürlich jetzt einen daemon laufen lassen, aber normal ist das doch nicht oder?
Fällt Euch dazu irgendwas ein?

Gruß & Dank
zoid

[rendegast]

aus kernel-parameters.txt:

Code: Alles auswählen

	clock=		[BUGS=X86-32, HW] gettimeofday clocksource override.
			[Deprecated]
			Forces specified clocksource (if available) to be used
			when calculating gettimeofday(). If specified
			clocksource is not available, it defaults to PIT.
			Format: { pit | tsc | cyclone | pmtmr }

	clocksource=	[GENERIC_TIME] Override the default clocksource
			Format: <string>
			Override the default clocksource and use the clocksource
			with the name specified.
			Some clocksource names to choose from, depending on
			the platform:
			[all] jiffies (this is the base, fallback clocksource)
			[ACPI] acpi_pm
			[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
				pxa_timer,timer3,32k_counter,timer0_1
			[AVR32] avr32
			[X86-32] pit,hpet,tsc,vmi-timer;
				scx200_hrt on Geode; cyclone on IBM x440
			[MIPS] MIPS
			[PARISC] cr16
			[S390] tod
			[SH] SuperH
			[SPARC64] tick
			[X86-64] hpet,tsc

und sonstige kernel-Doku zu den timern.

Und hier mal dmesg bzgl "clock|hpet|tsc|rtc":

[ 0.000000] Kernel command line: root=LABEL=startpart ro vga=0x305 video=vesafb:ypan printk.time=N printk.time=Y hpet=force ipv6.disable=1 ide1=udma2 2

[ 0.177832] pci 0000:00:01.0: Force enabled HPET at 0xfed00000

[ 0.256557] hpet clockevent registered
[ 0.256562] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
[ 0.256570] hpet0: 3 32-bit timers, 25000000 Hz
[ 0.257625] ACPI: RTC can wake from S4

[ 1.145292] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[ 1.145357] rtc0: alarms up to one year, y3k

[ 1.146348] rtc_cmos 00:04: setting system clock to 2010-03-12 08:06:24 UTC (1268381184)

[ 22.084470] Marking TSC unstable due to: cpufreq changes.
[ 22.260012] Clocksource tsc unstable (delta = -109590251 ns)

[ 2342.851870] vboxdrv: Trying to deactivate the NMI watchdog permanently...
[ 2342.851879] vboxdrv: Successfully done.
[ 2342.851884] vboxdrv: Found 1 processor cores.
[ 2342.852042] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 2342.852048] vboxdrv: Successfully loaded version 3.1.4_OSE (interface 0x00100001).

Vielleicht ändert sich das Verhalten, wenn nicht mit dynamischer CPU-Taktung gearbeitet wird?

[ZOiD]

... danke erstmal für die Antwort.
Dynamische Prozessortaktung habe ich nicht aktiviert, bei den quotes weiss ich nicht so recht, was Du mir damit sagen möchtest. (abgesehen vom Informationsgehalt)
HPET habe ich im bios auch schon testweise ausgestellt.

[rendegast]

Wenn Du mit dem kernel-Startparameter herumspielen möchtest,
http://www.kernel.org/doc/Documentation ... meters.txt
Andere wären, wie im dmesg-Quote, zBsp 'hpet=...'.
In anderen Dateien der kernel-Doku wird weiter auf die Sachen eingegangen, zBsp. hpet.txt
http://www.kernel.org/doc/Documentation/timers/

Falls Du keine Kernelsource herunterladen willst, kannst Du auch online nachlesen:
http://www.kernel.org/doc/Documentation/



Der dmesg-Quote als Beispiel, nach welchen Begriffen Du in Deinem dmesg mal schauen kannst,
erster Anlauf wären die für ''clocksource" möglichen Einstellungen.

"clock|hpet|tsc|rtc"
haben alle was mit (kernel-)Zeit zu tun,
High Precision Event Timer
Time Stamp Counter
Real Time Clock



Normalerweise geht die hochgetaktete Kernelzeit ja genauer als die unpräzise RTC des BIOS
(habe auch schon umgedrehte Fälle gesehen).
Normalerweise vergleicht ein laufender kernel seine Zeit mit der RTC und bestimmt dann deren Drift,
um als erstes Hilfsmittel nach längerem Ausschalten aus RTC und Drift eine möglichst genaue Zeit festzulegen.
Vielleicht holt sich Dein kernel die Zeit häufiger von der falschgehenden RTC ab? oder einem falschgehenden Zeitserver?





-----------------
Das Tool für die manuelle Ermittlung und Korrektur der Kernelzeit-Drift ist adjtimex,
Du hast schon erwähnt einen Zeitdienst, wie zBsp chrony oder openntpd, die das automatisch erledigen.
8 sec pro Stunde ist allerdings happig, mein chrony korrigiert pro Stunde vielleicht 0,1 sec.
Einige Zeitdienste können da ins schleudern geraten, da sie mit sehr kleinen Korrekturschritten arbeiten.

Der "Holzhammer" ist jede Stunde (oder öfter) ein Aufruf von ntpdate.

[ZOiD]

Vielleicht holt sich Dein kernel die Zeit häufiger von der falschgehenden RTC ab? oder einem falschgehenden Zeitserver?

... also wie gesagt, meine Versuche das in den Griff zu bekommen, lagen in der richtig Stellung der cmos Uhr zum booten, bzw. ein ntpdate auf z.B. ptbtime. Daran wird´s nicht liegen, aber nach einer halben Stunde uptime sind es dann schon wieder ein paar Sekunden. (ohne zwischendurch irgendeinen Abgleich gemacht zu haben.)
Dmesg sagt mir folgendes:

Code: Alles auswählen

[    0.000000] Fast TSC calibration using PIT
[    0.156446] checking TSC synchronization [CPU#0 -> CPU#1]: passed.

[    1.196707] rtc_cmos 00:04: RTC can wake from S4
[    1.196729] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    1.196756] rtc0: alarms up to one month, 242 bytes nvram
[    1.198255] Using IPI No-Shortcut mode
[    1.198449] rtc_cmos 00:04: setting system clock to 2010-03-12 13:55:29 UTC (1268402129)

Ich werde mal mit den Kernelparametern spielen, auch wenn ich mir da nicht so die grosse Hoffnung mache.

Das Tool für die manuelle Ermittlung und Korrektur der Kernelzeit-Drift ist adjtimex,
Du hast schon erwähnt einen Zeitdienst, wie zBsp chrony oder openntpd, die das automatisch erledigen.
8 sec pro Stunde ist allerdings happig, mein chrony korrigiert pro Stunde vielleicht 0,1 sec.
Einige Zeitdienste können da ins schleudern geraten, da sie mit sehr kleinen Korrekturschritten arbeiten.

Der "Holzhammer" ist jede Stunde (oder öfter) ein Aufruf von ntpdate.

... genau, den Holzhammer hatte ich schon ausgepackt, aber das stört mich irgendwie.
Stattdessen läuft z.Z. openntpd, was es scheinbar auch nicht in den Griff bekommt.

Code: Alles auswählen

System Events
=-=-=-=-=-=-=
Mar 12 15:07:51 s2 ntpd[18353]: clock is now synced
...
Mar 12 15:48:07 s2 ntpd[18353]: clock is now unsynced

[rendegast]

Den openntpd hatte ich auch erst in Verwendung,
mit seinem Schalter '-b' konnte er auch eine total falsche Zeit (durch win oder mich oder leere Batterie) direkt korrigieren.
Das funktionierte aber nur beim Start, ansonsten lief er der eigenen Korrektur hinterher.
(vielleicht funktionierte das Anpassen des Systemzeittaktes nicht?)

chrony jedoch konnte das damals, und auch heute,
wie an diesem Wert für 'frequency' zu sehen ist:

Code: Alles auswählen

# /tmp/adjtimex -p
         mode: 0
       offset: 0
    frequency: -145962
     maxerror: 16000000
     esterror: 16000000
       status: 64
time_constant: 2
    precision: 1
    tolerance: 32768000
         tick: 10000
     raw time:  1268409584s 447302us = 1268409584.447302
 return value = 5

(die Batterie ist gewechselt, win und linux gehen von einer UTC-RTC aus, und ich verfrickele mich nicht mehr so oft in der Zeiteinstellung)

[ZOiD]

Hallo nochmal,
also chrony scheint das ganz gut hinzubekommen.
Trotzdem frag ich mich natürlich noch woher das kommt, kann ja eigentlich nur am rel. neuen AMD chipsatz liegen, oder?

Danke für die Unterstützung.
zoid