After these changes, OpenBSD VMware guest's clock is galloping into the future like this: Aug 31 02:42:18 build ntpd[55904]: adjusting local clock by -27.085360s Aug 31 02:44:26 build ntpd[55904]: adjusting local clock by -116.270573s Aug 31 02:47:40 build ntpd[55904]: adjusting local clock by -281.085430s Aug 31 02:52:01 build ntpd[55904]: adjusting local clock by -320.064639s Aug 31 02:53:09 build ntpd[55904]: adjusting local clock by -385.095886s Aug 31 02:54:47 build ntpd[55904]: adjusting local clock by -532.542486s Aug 31 02:58:33 build ntpd[55904]: adjusting local clock by -572.363323s Aug 31 02:59:38 build ntpd[55904]: adjusting local clock by -655.253598s Aug 31 03:01:54 build ntpd[55904]: adjusting local clock by -823.653978s Aug 31 03:06:14 build ntpd[55904]: adjusting local clock by -926.705093s Aug 31 03:09:00 build ntpd[55904]: adjusting local clock by -1071.837887s
VM time right after boot: rdate -pn $ntp; date Sat Sep 3 13:39:43 MSK 2022 Sat Sep 3 13:43:24 MSK 2022 $ sysctl -a | grep tsc kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) machdep.tscfreq=580245275 machdep.invarianttsc=1 And in a couple of minutes after boot the timeskew getting like this: $ rdate -pn $ntp; date Sat Sep 3 13:41:49 MSK 2022 Sat Sep 3 13:48:46 MSK 2022 After several hours the VM lives in tomorrow. As a workaround, changing TSC source helps: # sysctl kern.timecounter.hardware=acpihpet0 -- With best regards, Pavel Korovin
