Debian, VMWare und Uhrzeit

[openconcept]

Hallo zusammen - jetzt brauche ich die Hilfe von debian Spezialisten

Habe ein openSuse Linux als Basissystem. Darauf vmware Server 1.05 und darin eine virtuelle Installation eines Debian Etch mit Kernel 2.6.18-6-686. Läuft alles soweit i.o. In der Virtuellen Umgebung habe ich NT4, Win2000 und Win2003 Server, WinXP, Suse 9.2, Suse 9.3 und OpenSuse 10 am laufen. Und neu eben auch ein Debian (möchte eigentlich alles auf Debian wechseln).

Das Problem: Auf allen Systemen stimmt die Uhrzeit, nur auf Debian nicht. Bin aber der Meinung, dass Kernel Parameter usw. gleich wie auf den Suse Systemen eingestellt ist. Ich habe folgendes Verhalten:
Im /etc/rc.local setzt ich mit ntpdate-debian -b die Systemzeit über unsere NTP Server. Diese stimmt auch perfekt. Allerdings ist dann die Zeit bereits nach dem Login (also etwa 10 Sekunden später) schon 35 Sekunden voraus. Danach läuft die Uhr eigentlich stabil mit diesen 35 Sekunden Vorsprung. Ein erneutes ntpdate-debian setzt die Uhrzeit richtig und alles läuft perfekt.

Nun möchte ich eigentlich nicht einen Chron Job basteln, der mir die Zeit richtig setzt, sonder verstehen was da abgeht. Was läuft nach rc.local noch gross ab (kenne Debian leider noch nicht gut)? Sonstige Ideen, was da schief läuft?

Allgemeine Tipps zum VMWare Zeit Problem:
- Im Bios vom Host System sämtlich Stromsparmechanismen wie SpeedStep oder C1E ausschalten.
- Im Host Betriebssystem Power Save Demon ausschalten und /etc/vmware/config wie folgt anpassen:
host.cpukHz = 2330000 (Erfahrungswert: Die Gigazahl von /proc/cpuinfo eingeben (also etwas schneller als wirklich)
host.noTSC = TRUE
ptsc.noTSC = TRUE

- In der vmx-Datei des Gastsystems folgendes ergänzen:
tools.syncTime = "TRUE"

- Im Gastsystem kein NTP brauchen, sondern die Zeit über die VMWare-Tools synchronisieren. Dafür muss nur vmguestd laufen ( ps aux|grep vmware-vmguestd)

- Im Gastsystem folgende Kernelparameter verwenden:
clock=pid nosmp noapic nolapic nohz=off

Vielen Dank

[openconcept]

Niemand eine Idee?

[pluvo]

Niemand eine Idee?

Ich kenne das Problem. Ich lasse meistens dann doch einen ntp-Dienst laufen

Wie wäre es wenn du auf ntpdate verzichtest und das Paket ntp einsetzt?

mfg pluvo

[openconcept]

Werde ich mal versuchen. Schaltest du dann die VMWare Zeitsynchronisation aus?

[cosmac]

hi,

ntpdate und ntp sind doch nur ein Würgaround. 35 Sekunden Offset ist ja ein ganz anderes Problem, als die üblichen Uhrenfehler. Probier' mal, die Init-Scripte hwclock und hwclockfirst nicht zu starten. Die müssten an insgesamt 3 Stellen auftauchen.

Nachteil: Microsoft-Dateisysteme laufen dann nicht nicht mehr mit localtime sondern mit UTC.

[Danielx]

Was sagt denn:

Code: Alles auswählen

grep HPET /boot/config-`uname -r`

[openconcept]

Was sagt denn:

Code: Alles auswählen

grep HPET /boot/config-`uname -r`

Code: Alles auswählen

CONFIG_HPET_TIMER=y
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y

[Danielx]

Welchen Kernel hast du denn?

Aktiviere mal CONFIG_HPET_EMULATE_RTC=y in der Config, das geht bei 2.6.18 und 2.6.24 über:
Device Drivers ---> Character devices ---> Enhanced Real Time Clock Support
mit "make menuconfig" und backe dann den Kernel neu.

Ab Kernel 2.6.25 ist das in Debian schon aktiviert.

Das hat bei mir das Problem behoben.

Gruß,
Daniel

[openconcept]

Was ich probiert habe:

• 1. boot parameter hpet=disabled gesetzt. hat nichts bewirkt

• 2. /etc/init.d/hwclock.sh umbenannt. hat nichts bewirkt

im moment bringt folgendes im rc.local ein brachbares resultat:

Code: Alles auswählen

(sleep 600; ntpdate-debian -b ntp1.admin.lan) 2>&1 >>/var/log/messages &

Allerdings ist das ein gemurgse... Weitere Ideen?

[gucki]

Hallo,

dieses Problem scheint mit VMWare Server 1 und CPU's, die dynamisch Ihre Taktfrequenz ändern, zusammen zuhängen. Ein Update auf VMWare Server2 hat bei mir das Problem behoben.

Die 2er Version ist aktuell RC2. Läuft aber schon recht zuverlässig. Seit RC2 geht eigentlich alles ohne Probleme. Einzig das es nur noch ein Webfrontend zum managen gibt, find ich nicht so toll. Aber man gewöhnt sich dran.

Gruß Gucki

[openconcept]

Welchen Kernel hast du denn?

Aktiviere mal CONFIG_HPET_EMULATE_RTC=y in der Config, das geht bei 2.6.18 und 2.6.24 über:
Device Drivers ---> Character devices ---> Enhanced Real Time Clock Support
mit "make menuconfig" und backe dann den Kernel neu.

Ich habe 2.6.18. Werde das gelegentlich einmal durchspielen. Vielen Dank für den Tipp.

[Danielx]

und CPU's, die dynamisch Ihre Taktfrequenz ändern, zusammen zuhängen.

Ja, ich meine mich erinnern zu können, dass ich das auch mal gelesen habe.
Wenn VMWare damit nicht richtig damit umgeht ist es durchaus möglich, dass die Uhr dann mal schneller oder langsamer läuft, sozusagen je nach aktueller Taktfrequenz.

Gruß,
Daniel

[gucki]

und CPU's, die dynamisch Ihre Taktfrequenz ändern, zusammen zuhängen.

Ja, ich meine mich erinnern zu können, dass ich das auch mal gelesen habe.
Wenn VMWare damit nicht richtig damit umgeht ist es durchaus möglich, dass die Uhr dann mal schneller oder langsamer läuft, sozusagen je nach aktueller Taktfrequenz.

Gruß,
Daniel

den komischen Versatz von ca 30sec erklärt es eigentlich nicht, hat mich aber auch zum Wahnsinn gebracht. Erst die 2er Version löste das Problem.

[Danielx]

den komischen Versatz von ca 30sec erklärt es eigentlich nicht, hat mich aber auch zum Wahnsinn gebracht.

Hm, bei mir hat sich der "Versatz" immer weiter vergrößert.