On Tue, Feb 23, 2016 at 06:31:59PM -0800, Owen Hofmann wrote: > Specifically, what underlying source of time should be exposed through > kvm-clock and other paravirtual ABIs like the HyperV reference tsc > page? Recently a couple of threads on kvm-list, along with attempts > to produce reliable behavior from kvm-clock on our systems have What is there in place are testcases to measure particular kvmclock issues, such as time backwards events and maximum offset/frequency against NTP. There is no "true" clock, you can only measure one clock against another (i think Radim raised that point as well). UTC is the global standard, an average of atomic clocks. http://tf.nist.gov/general/pdf/1498.pdf What you'd like to do is measure kvmclock stability regarding some parameter. So to improve that situation one could find what parameters are important (such as whether clock-A should not stop counting for more than some time units of clock-B, thats the "opposite" side effect of the bug uncovered by Hyper-V fixes, the other being time backwards events). (clock-A being kvmclock, clock-B being a GPS clock for example). One useful activity would be to compare (only the minimum measurements out of many measurements) kvmclock in a guest with a GPS clock. I bought a Garmin GPS clock but never got around to enabling the RS-232 connection required to bypass the USB latency. It costs less than 100US$. http://www.lammertbies.nl/comm/info/GPS-time.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
