Problem mit Timekeeping - noTSC?

[vbs]

Hi Ihr,

ich schlage mich seit ein paar Tagen mit einem Problem der Zeitsynchronisierung (bzw. Timekeeping) in meiner VM rum. Wäre klasse, wenn ich mal die Experten hier fragen könnte, was sie davon halten.

Und zwar ist das Problem, dass die Uhrzeit meiner VM permanent zu langsam läuft. Nach ungefähr 12 Stunden hängt die Uhr schon ca. 1 Minute hinterher. Ich hab zwar inzwischen eine funktionierende Konfiguration gefunden, aber bei mir sind Zweifel geblieben.

Bei dem Host handelt es sich um ein Windows 10 x64 System mit Intel i3 3220 und MSI H77MA-G43 Mainboard. Als Gastsystem ist Ubuntu 16.10 x64 installiert. VMWare ist 12.5.2 build-4638234.

Laut dem BestPractice Guide (https://kb.vmware.com/selfservice/micro ... Id=1006427) sind dabei für den Gast keine weiteren Kernel-Parameter notwendig und es wird empfohlen, ntpd anstatt VMWare's timesync-Options zu verwenden. Das hab ich auch so konfiguriert.

In den Ausgaben von "ntpq -p" sehe ich dann jedoch, dass der Offset permanent wächst (ich habe den ntpd mit Parameter "-x" im slew mode laufen, damit ntpd die Zeit nie hart setzt).

Außerdem hab ich diese Troubleshooting-Seite durchgearbeitet (https://kb.vmware.com/selfservice/micro ... 0780582396):
Mit der Option "timeTracker.periodicStats" sehe ich keine verpassten Interrupts (immer "TimeTrackerStats behind by 0 us").
Auch die CPU-Frequenz vom Host wird im Logfile offenbar korrekt mit 3.3 GHz erkannt.

Also eigentlich war ich der Meinung, alles richtig konfiguriert zu haben. Trotzdem eben dieses Problem leider

Dann hab ich aber hier was gefunden, was das Problem mindestens augenscheinlich gelöst hat:
Nach dieser Seite hier (https://kb.vmware.com/selfservice/micro ... nalId=1591), habe ich in meine config.ini von VMWare diese Zeilen eingefügt:

Code: Alles auswählen

host.noTSC = TRUE
ptsc.noTSC = TRUE

Ich konnte nicht rausfinden, was die Optionen eigentlich bewirken, aber das Setzen des Kernel Parameters "notsc" hat offenbar nicht den gleichen Effekt.

Das scheint das Problem nun auch tatsächlich behoben zu haben! Die Zeit ist jetzt sehr stabil und mit ntpd hab ich nun einen Offset <5 ms Also ziemlich traumhaft, denk ich.

Code: Alles auswählen

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.000
#ntp.wdc1.us.lea 130.133.1.10     2 u    7   64  377  100.664    2.549   0.122
+ntp0.as34288.ne 85.158.25.74     2 u   16   64  337   28.728    2.212   0.238
-ntp10.icmp.dk   173.34.166.174   2 u   18   64  377   34.147   -1.229   0.270
-195.50.171.101  145.253.3.52     2 u   12   64  377   13.986   -0.167   0.387
#78.154.171.62 ( 62.149.0.30      2 u   11   64  377   56.393   -0.576   2.992
#ntp3.inx.net.za 238.72.153.243   2 u   11   64  377  195.877   -1.558   0.154
+www.bhay.org    85.199.214.98    2 u   11   64  377   27.748    1.035   0.210
-5ED0A51A.cm-7-1 193.79.237.14    2 u   12   64  377   35.127    0.325   1.657
-eternity.kno-te 200.98.196.212   2 u   15   64  377   94.974   -0.720   0.181
-cheezum.mattnor 66.228.59.187    3 u   10   64  377  129.679   -0.438   0.151
*ntp4.bit.nl     .PPS.            1 u   11   64  377   18.136   -0.924   0.189
-46.182.19.75    141.82.25.202    3 u   17   64  377   23.762   -1.547   4.851
#mdnworldwide.co 127.67.113.92    2 u    8   64  377  158.822   -1.750   0.109
-juniperberry.ca 17.253.34.125    2 u   24   64  377   27.626    1.064   0.139


Aber irgendwie traue ich dem Braten nicht so recht: wenn diese beiden noTSC-Optionen so eine tolle Sache sind, warum sind sie dann nicht default? Also gibts evtl. Nachteile an den Optionen? Ist es wirklich empfehlenswert die so zu nutzen?

Und wie verhält sich das innerhalb der VM, wenn der Host durch Energiesparmaßnahmen die Taktfrequenz der CPU(s) verändert? Ich habe schon mehrmals gelesen, dass man solche Energiesparfunktionen ausschalten muss, um eine stabile Uhr im Gastsystem zu bekommen. Ist das (noch) so? Würde ich natürlich ungern tun, da ja dann der Host ständig auf Maximaltakt laufen würde.

Ich danke euch wirklich sehr für jede Hilfe!

Achso, hier noch die Daten.
vmx: http://pastebin.com/eeXYNtjX
config.ini: http://pastebin.com/RLj6dcTh
vmware.log: http://pastebin.com/Pcvr95Mj

[~thc]

Und zwar ist das Problem, dass die Uhrzeit meiner VM permanent zu langsam läuft. Nach ungefähr 12 Stunden hängt die Uhr schon ca. 1 Minute hinterher.

Das wäre dann eine Drift von 1,4 Promille - da hatte ich unter dem VMWare Server 1 und meinen ersten produktiven Linux-VMs ganz andere Geschwindigkeiten...

Laut dem BestPractice Guide (https://kb.vmware.com/selfservice/micro ... Id=1006427) sind dabei für den Gast keine weiteren Kernel-Parameter notwendig und es wird empfohlen, ntpd anstatt VMWare's timesync-Options zu verwenden. Das hab ich auch so konfiguriert.

Ja, und dann wären deine Sorgen eigentlich behoben, aber...

In den Ausgaben von "ntpq -p" sehe ich dann jedoch, dass der Offset permanent wächst (ich habe den ntpd mit Parameter "-x" im slew mode laufen, damit ntpd die Zeit nie hart setzt).

...dann möchtest du nicht, das ntpd die Zeit setzt?

Der Parameter "-x" setzt laut manpage das "slew interval" von 128 ms auf 600 s (Faktor 3000) - so dauert die Korrektur der Drift dann absichtlich ewig.

Warum setzt du diesen Parameter?

[vbs]

Laut dem BestPractice Guide (https://kb.vmware.com/selfservice/micro ... Id=1006427) sind dabei für den Gast keine weiteren Kernel-Parameter notwendig und es wird empfohlen, ntpd anstatt VMWare's timesync-Options zu verwenden. Das hab ich auch so konfiguriert.

Ja, und dann wären deine Sorgen eigentlich behoben, aber...

In den Ausgaben von "ntpq -p" sehe ich dann jedoch, dass der Offset permanent wächst (ich habe den ntpd mit Parameter "-x" im slew mode laufen, damit ntpd die Zeit nie hart setzt).

...dann möchtest du nicht, das ntpd die Zeit setzt?

Doch doch, ich möchte schon den ntpd benutzen und tue ich ja auch, habe ich vlt. blöd erklärt. Das Problem ist, dass die Uhr der VM so stark zu langsam läuft, dass der Offset immer größer wird. Sobald der Offset dann den "step threshold" überschreitet, dann setzt ntpd die Zeit hart was zu einem Zeitsprung im System führt. Und das möchte ich nicht, weil das Prozesse im System verwirrt.
Also meiner Meinung nach läuft die Uhr so stark falsch, dass das von ntpd nur mit steps zu korrigieren ist -> schlecht.

Der Parameter "-x" setzt laut manpage das "slew interval" von 128 ms auf 600 s (Faktor 3000) - so dauert die Korrektur der Drift dann absichtlich ewig.
Warum setzt du diesen Parameter?

Das hab ich nur zu Debugzwecken gemacht, damit ich in Ruhe die Veränderung des Offsets beobachten kann. Wenn ich "-x" nicht setze, dann überschreitet das System innerhalb von Minuten den Offset von 128 ms und ntpd setzt die Zeit hart.

[~thc]

Laut ntpd-Manpage darf der ntpd alle 128 ms um die 5 ms pro Sekunde per "slew" eingreifen. Das wären nach meiner Rechnung maximal 168 Sekunden alle 12 Stunden. Das sollte bei deinem Drift also eigentlich passen.

[vbs]

Hm, hast du da einen Link zu? Ich denke, da ist ein Komma verrutscht
Die manpage sagt mMn was anderes (und ich habe auch andere Zahlen im Hinterkopf). Ich beziehe mich zB auf die hier:
https://linux.die.net/man/8/ntpd

Da steht:

The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based.

Also lass uns rechnen:
1 PPM -> 0.0001%
500 PPM -> 0.05%

Also innerhalb von 1000 ms wird ntpd nur maximal um 0.05% korrigieren:
0.05% von 1000 ms -> 0,5 ms

Also für mich heißt das: ntpd korrigiert pro Sekunde um maximal 0,5 ms.

12 Stunden haben 43200 Sekunden. Das heißt in dieser Zeit korrigiert ntpd maximal 21600 ms, also 21,6 Sekunden. Da liege ich dick drüber, leider.

Wie dem auch sei, unabhängig von der Rechnung (die ich aber für plausibel halte):
ntpd setzt wirklich bei mir regelmäßig hart die Zeit. Sehe ich immer daran, dass systemd meldet "time has been changed".

[Dayworker]

Gibt es einen bestimmten Grund, weshalb du bei Ubuntu auf die halbgaren Ergüsse abseits der LTS-Version setzt?
Meine letzte Info war, daß Canonical nur die LTS-Version stabil hält und die halbjährlichen Versionen zum Testen nutzt. Damit sind diese lediglich dafür interessant, bisher nichtunterstützte HW anzusprechen und die gibt es in einer VM höchstens in Form der CPU.

[vbs]

Tatsächlich hatte ich bis vor kurzem die 16.04 laufen. Jedoch hat der ntpd regelmäßig eine komische Fehlermeldung geworfen (weiß leider nicht mehr was genau). Kritisch war das aber wohl nicht. Google sagte, dass das ein bekanntes Problem in der speziellen Version von ntpd war. Das hatte ich dann zum Anlass genommen, mal die 16.10 zu versuchen. Mit dem ntpd in 16.10 kam die Meldung dann auch nicht mehr.

[Dayworker]

Welche 16.04 lief bei dir genau?
Eventuell hättest du dein Problem bereits mit dem https://wiki.ubuntu.com/Kernel/LTSEnablementStack als Version LTS-16.04.1 lösen können. Der Kernel aus 16.10 dürfte inzwischen auch seinen Weg in die LTS-Version 16.04.2 gefunden haben oder auch demnächst finden. Von daher gibt es absolut keine oder nur wenige Gründe, um keine LTS-Version zu nutzen.

[vbs]

Ja, evtl. ist das so. Willst du darauf hinaus, dass meine Uhr jetzt evtl. wegen dem 16.10-Kernel zu langsam läuft bzw. dass mein eigentliches Problem mit 16.04 nicht auftreten würde?

[~thc]

Also mit den 5 ms - das war ein Tippfehler - es sind 0.5 ms. Und da der ntpd alle 128 ms korrigieren darf (rund 8 mal pro Sekunde), kommt man auf die größere Zahl an Sekunden - aber das ist graue Theorie.

Ich hab das mal mit dem Player 12.5.2 und einer Debian 8 VM nachvollzogen - das ist ja schon ein bisschen abenteuerlich. Die Zeit rauscht innerhalb von ca. 20 Minuten um 2 Sekunden vor und dann korrigiert der ntpd die Zeit jedes mal. Auch bei installierten Tools (Open VM Tools) und der Option der Zeitanpassung durch diese wird die Zeit dann von den Tools hart alle zwei Minuten neu gesetzt.

TSC ist mit hoher Wahrscheinlichkeit der "Time Stamp Counter" des Prozessors, der als Zeitquelle dienen kann. Mit diesen Optionen nutzt die Workstation ihn dann nicht - ob das Auswirkungen auf die Energiesparmodi des Prozessors hat, kann ich nicht sagen - ich würde aber intuitiv erst mal nicht davon ausgehen.

[vbs]

TSC ist mit hoher Wahrscheinlichkeit der "Time Stamp Counter" des Prozessors, der als Zeitquelle dienen kann. Mit diesen Optionen nutzt die Workstation ihn dann nicht

Das komische ist, dass der Guest-Kernel weiterhin (also mit noTSC in der config.ini) der Meinung ist, TSC zu nutzen:

Code: Alles auswählen

root@minion:/var/www# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc


Wenn ich notsc als Kernel-Parameter setze, dann taucht er tatsächlich nciht mehr auf in current_clocksource, behebt das Problem jedoch nicht

- ob das Auswirkungen auf die Energiesparmodi des Prozessors hat, kann ich nicht sagen - ich würde aber intuitiv erst mal nicht davon ausgehen.

Unabhängig von dem TSC (ja, das ist eine Zeitquelle für den Kernel -> /sys/devices/system/clocksource/clocksource0/available_clocksource):
Ist es für das Timekeeping der VM generell ein Problem, wenn der Host durch Energiesparmaßnahmen dynamisch seine Taktfrequenz ändert? Sprich: Muss man wirklich beim Host solche Energiesparmaßnahmen deaktivieren, wenn man ein gutes Timekeeping will?

Generell aber interessant, dass du das Problem erstmal so nachvollziehen konntest. Kannst ja mal gucken, ob diese "noTSC"-Option in der config.ini auch sofort die Lage drastisch verbessert. Ist für mich im Moment so eine Art "Wunderoption"

[JustMe]

Also, eigentlich koennte die Sache doch ganz klar sein...

Wenn in der VM-Konfiguration "noTSC" gesetzt wird, dann gibt die Virtualisierung den nicht durch, sondern stellt selbst "so etwas" in der Virtualisierungsschicht zur Verfuegung-> Problem behoben, auch wenn der Kernel meint, Zugriff auf einen TSC zu haben.

Wenn man versucht, den durchgereichten, und in der Virtualisierung ganz sicher nicht monoton laufenden TSC vom Kernel verwalten zu lassen, der davon ausgeht, genau einen solchen zu erhalten, dann gibt's halt Probleme.

Und dass die VM-Gaeste direkten Zugriff auf Stromsparfunktionen von Prozessoren erhalten, will ich mal vorsichtig in's Reich der Fabeln verbannen. Da wird ganz sicher "der Wunsch" entgegengenommen und an den Gast bestaetigt, aber der Hypervisor (egal ob hosted wie in der WS, oder bare metal wie im ESXi) hat mit der Prozessorleistung ganz andere Sachen zu bearbeiten, als die nach Gastwunsch schlafen zu legen.

Deswegen ist in der Virtualisierung die Verwendung von Timern ja so schwierig, und, soweit es irgend geht, die Nutzung von externen Taktquellen wie z.B. per ntp zu bevorzugen.

Jetzt mal ganz davon abgesehen, dass dem TSC wegen Einschraenkungen sowieso kein Vorzug gegenueber dem HPET gegeben werden sollte.

Just my 2c.

[~thc]

Kannst ja mal gucken, ob diese "noTSC"-Option in der config.ini auch sofort die Lage drastisch verbessert. Ist für mich im Moment so eine Art "Wunderoption"

Hatte ich nur nicht erwähnt - dann wird aus dem großen Vorwärts-Drift ein kleiner Rückwärts-Drift.

[Dayworker]

Mit dem kleinen Rückwärtsdrift kann man besser arbeiten als anders herum. Zeit läuft ja vorwärts und deshalb sollten auch Programme damit besser zurechtkommen, wenn die Zeit in positiver Richtung verändert wird. Einige Programme reagieren weit allergischer, wenn die Zeit alle naselang in die Vergangenheit springt. Programme wie rsync oder Robocopy, die für die Sicherung einer Datei den letzten Schreibzugriff auswerten, sind auf eine positive Zeit des Schreibzugriffs angewiesen. Anderfalls wird eine Datei nicht oder auch nie gesichert, weil das Backup bereits einen neueren Zeitstempel trägt.


[add]
Unabhängig davon gilt, wer mit Virtualisierung arbeitet, sollte von irgendwelchen Stromspar-Funktionen Abstand halten. Der ESXi kommt damit noch am besten klar, da er ja direkt auf der HW aufsetzt. Trotzdem kann ihn eine querschiessende VM in Bedrängnis bringen, wenn diese unaufhörlichen einen Energiesparzustand einstellen will. Was Linux schon seit dem 2.6er Kernel beherrscht, nämlich die virtualisierte Ausführung, hat Winzigweich erst bei Win-Server2k12 geschafft. Vorher kennt kein Win-OS eine virtualisierte Ausführung und wähnt sich als Herrscher über die gesamte HW.

[vbs]

Wenn man versucht, den durchgereichten, und in der Virtualisierung ganz sicher nicht monoton laufenden TSC vom Kernel verwalten zu lassen, der davon ausgeht, genau einen solchen zu erhalten, dann gibt's halt Probleme.

Aber das scheint ja die Default-Einstellung zu sein. Klingt ja alles plausibel, danke dafür, aber warum muss man das dann erst händisch umstellen? Klingt ja so als sei das sowieso keine gute Idee, den TSC vom Host zu verwenden.

Und dass die VM-Gaeste direkten Zugriff auf Stromsparfunktionen von Prozessoren erhalten, will ich mal vorsichtig in's Reich der Fabeln verbannen.

War dann wohl ein Missverständnis. Das hab ich so zumindest nicht gemeint. Meine Frage war eigentlich nur, ob es die System-Uhr der VM durcheinander bringen kann, wenn der Host seine Stromsparfunktionen aktiviert und seine Host-CPU-Frequenz ändert. Scheinbar hängen ja einige Zeitquelle in der VM direkt am CPU-Takt des Hosts?

Unabhängig davon gilt, wer mit Virtualisierung arbeitet, sollte von irgendwelchen Stromspar-Funktionen Abstand halten. Der ESXi kommt damit noch am besten klar, da er ja direkt auf der HW aufsetzt. Trotzdem kann ihn eine querschiessende VM in Bedrängnis bringen, wenn diese unaufhörlichen einen Energiesparzustand einstellen will. Was Linux schon seit dem 2.6er Kernel beherrscht, nämlich die virtualisierte Ausführung, hat Winzigweich erst bei Win-Server2k12 geschafft. Vorher kennt kein Win-OS eine virtualisierte Ausführung und wähnt sich als Herrscher über die gesamte HW.

Aber du bist jetzt bei Stromsparfunktionen in der VM und auf im Host, oder?

[Dayworker]

Wenn du mit Virtualisierung auch auf dem Desktop hantierst, braucht diese möglich gleichförmige Ressourcen und wenn der Host bei jeder sich ihm bietenden Gelegenheit einen Stromsparmodus aufsucht, ist das kontraproduktiv für alle darauf laufenden Programme und VMs sind im Endeffekt nix anderes als Prozesse mit dem Namen "vmware-vmx".

Bei Timing-Problemen in einer VM sollte man vielleicht auch mal nachsehen, mit welcher Zeitauflösung der Host-Kernel arbeitet. Ich meine das Ubuntu da virtualisiert normalerweise mit 250msec drangeht, andere Distributionen liegen mit 100msec deutlich drunter oder verwenden sogar Echtzeit-Kernel. Das kann auch für einige Ungereimtheiten sorgen, wenn das Host-OS eine wesentlich feinere Zeitauflösung fährt und dann für eine andere Zeitauflösung dolmetschen muß. Dadurch rennt dann das Gast- je nach Host-OS entsprechend vor oder hängt nach.


[add]
Ja sowas sollte normalerweise die Virtualisierungslösung ohne Probleme meistern, aber VMware hat keine eigene SW-EW für die Desktopprodukte mehr sondern vergibt diese als Auftragsarbeit und das kann für zusätzliche Bugs sorgen.

[vbs]

Ich danke euch erstmal ganz dolle! So wie ich das sehe, ist das prinzipiell erstmal kein grundsätzliches Problem mit dem notsc und im Moment läufts ja auch gut. Werde ich also erstmal so laufen lassen, danke!