Re: Uhrzeit rennt auf XEN-Server weg

Hi hi,

danke fuer die ausfuehrlich erklaerung :-) die details und ihre
auswirkungen waren mir bisher nicht klar...

ich weiß das ntpd das problem nicht wirklich loest aber es kann das
problem 'fixen' fuer all diejenigen die keine C & fbsd-kernel interna
kentnisse haben (mich eingeschlossen).

@Matthias Fechner
welche version fährst du genau? ich weiß nicht genau ob der fix von
8-CURRENT auch auf die anderen XEN projekte portiert wurde. hier wäre
adrian chadd der ansprechpartner, er hat das problem in 8-CURRENT
gefixt.

Regards,

---
Mr. Olli
On Thu, 2009-07-02 at 08:53 +0200, Oliver Fromme wrote:
> 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
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message