Re: Uhrzeit rennt auf XEN-Server weg

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 2 Jul 2009 08:53:09 +0200 (CEST)

Matthias Fechner wrote:
> Mister Olli schrieb:
> > der tipp mit 'kern.hz=100' ist extrem gut, sonst wird auch die
> > performance & reaktionszeit zu gering sein.
>
> ja, hab ich mal gesetzt.

Ja, das betrifft alle VMs (auch qemu usw.). Der HZ-Wert in
der VM sollte immer geringer als im Host-System sein, sonst
führt das zu allen möglichen Timing-Problemen. Bei FreeBSD
ist der "klassische" Default von 100 empfehlenswert.

> > <--- les dich mal durch die ntpd man page ich weiss den namen des
> > parameters grad nicht mehr ;-))
>
> es scheint die Option tinker zu sein, aber in der man page wird
> daraufhin gewiesen, das man diese Option nicht unbedingt setzen soll,
> wenn man nicht genau weiss was man macht.

Ich glaube, es sind die Optionen -g und/oder -x gemeint.
Die helfen aber bei dem zugrundeliegenden Problem nicht.

Der ntpd ist dafür gedacht, die normale physikalische
Abweichung einer Quarz-Uhr, wie sie in jedem PC verbaut
ist, zu kompensieren, d.h. ein paar Sekunden pro Tag.

Wenn die Uhr _massiv_ zu schnell oder zu langsam läuft,
wie das hier der Fall ist, dann sollte man die eigentliche
Ursache dafür beheben. Zu versuchen, mit dem ntpd an den
Symptomen herumzudoktorn, ist keine gute Idee.

Standardmäßig führt der ntpd die Uhr stufenlos nach,
solange die Abweichung nicht größer als 128 ms ist.
Dies ist mit einer Geschwindigkeit von maximal 0.05%
möglich, was einer Abweichung von knapp 45 s pro Tag
entspricht (die ist ein Limit der PLL/FLL-Logic im
Kernel, nicht im ntpd).

Ist aber die Qualität der Uhr schlechter, kann die Zeit
nicht mehr nachgeführt werden, sondern der ntpd muss
ständig "Sprünge" ausführen, was schlecht ist, da dann
alles, was mit Zeitmessung zu tun hat, zunehmend ungenau
wird. Das betrifft z.B. die verschiedenen Statistik-
Funktionen im Kernel, anhand derer der System-Load und
Resource-Usage ausgerechnet wird. Diese Daten wiederum
werden vom Process-Scheduler verwendet, was unter ungün-
stigen Umständen dazu führen kann, dass das Scheduling
darunter leidet, was man an schlechterer interaktiver
Response u.ä. feststellen kann. Auch die I/O-Funktionen
und andere wichtige Teile des Kernels und des Userlands
hängen teilweise von einem funktionierenden Time-Keeping
ab.

Mit den genannten ntpd-Optionen kann man verhindern, dass
der Daemon sofort stirbt, wenn er feststellt, dass die
Abweichung der Uhr zu groß ist. Aber obige Probleme kann
man damit nicht beseitigen.

Langer Rede kurzer Sinn: Versuch erstmal, HZ auf 100 zu
setzen, notfalls sogar auf 80 oder 50. Geht die Uhr dann
immer noch massiv falsch, könmnte ein Update auf 8-current
helfen (was zur Zeit im Code-Freeze ist und meiner Meinung
nach relativ gut läuft).

Wie gesagt: ntpd hilft nur dann etwas, wenn die Abweichung
im normalen Rahmen ist, wie bei einer normalen Quarz-Uhr.
In dem Fall solltest Du die VM gegen die Uhr des Host-
Systems synchronisieren (ich nehme an, dass dort auch ein
ntpd läuft), oder zumindest gegen einen Zeitserver innerhalb
Deines lokalen Netzes. Es ist Quatsch, zu versuchen, die VM
direkt gegen einen externen Zeitserver (z.B. *.pool.ntp.org)
zu synchronisieren.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"In My Egoistical Opinion, most people's C programs should be indented
six feet downward and covered with dirt."
        -- Blair P. Houghton
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 02 Jul 2009 - 08:53:41 CEST

search this site