On Tue, 19 Nov 2019 at 21:20, Ian Gregory wrote:
> I can
> confirm that change resolved the precision issue described in the
> linked thread, but it also seems to have resulted in much improved
> clock stability (4 steps in 24hr, 1.0s, 1.0s, 0.5s, 0.5s).
Correction - there were actually 3 instanc
As a final update to this (for now): I was unable to work out why the
correct timestamps from pvclock_get_timecount() were not being used to
correct the system clock. I suspect I don't have a full enough
understanding of how the return value from this function used by the
kernel timekeeping process
I continued to investigate this and added some debugging output to the
pvclock driver to attempt to work out what was going on.
In my most recent test I rebooted the client VM at 08:10 yesterday.
Over the following 24h, there were 16 "clock step" events which caused
the time to lag real time by a
Hi
Since the 6.6 release I've been experimenting with using pvclock as
the selected timecounter on a virtual machine running under vmm. Both
the host and guest are running 6.6-stable (the environment is provided
by openbsd.amsterdam).
With 6.5 and the tsc source, the clock would drift linearly by
4 matches
Mail list logo
