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.
![:)]( "Smile")
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
![:(]( "Sad")
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:
host.noTSC = TRUE
ptsc.noTSC = TRUEIch 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
![:)]( "Smile")
Also ziemlich traumhaft, denk ich.
Code:
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/eeXYNtjXconfig.ini:
http://pastebin.com/RLj6dcThvmware.log:
http://pastebin.com/Pcvr95MjStatistik: Verfasst von vbs — 10.02.2017, 19:08
),