On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote: > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote: > > On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote: > > > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ > > > > of the host clock. > > > > > > That is pretty good. > > > > Yes. > > > > > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() - > > > > guest_tsc) part ? > > > > > > Yes, it results in simpler code, doesn't create dependency on the > > > dreaded kvmclock, and is the best we can currently do wrt. precision. > > Even if the PHC sync algorithm manages to detect that the clock read is > incorrect, consider the following: > > Variability in the VM-entry code path, such as cache effects and interrupts would cause > certain readings to be longer then the average (assuming an average > where cache is hot). > > Using the TSC removes this variability, which can be large in case of > non realtime guests, where you do: > > 1. kvm_hypercall. > 2. read host realtime clock. > 3. schedule out qemu-kvm vcpu. > 4. schedule in qemu-kvm vcpu. > > So using the delta between read host realtime and > ->gettime64 increases precision and decreases variability. > > > Sorry, unless i am misunderstanding how this works, it'll get the guest clock > > 2us behind, which is something not wanted. > > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, > > this means Chrony will sync the guest clock to > > > > host realtime - 2us > > > > Is that correct? Drop the offset correction and the following happens: Clock offset seems to vary between negative hundreds of ns: 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 0 3 377 11 -131ns[ -309ns] +/- 3ns And positive: 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 0 3 377 4 +79ns[ +155ns] +/- 3ns -- 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
