From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 3/3] PTP: add kvm PTP driver Date: Mon, 16 Jan 2017 18:01:14 -0200 Message-ID: <20170116200112.GB8739@amt.cnet> References: <20170113155657.GD22440@potion> <20170113174014.GA9310@amt.cnet> <20170116162653.GA32097@potion> <20170116165411.GA2386@potion> <20170116170827.GB2501@amt.cnet> <20170116172758.GB31452@potion> <20170116173909.GA4639@amt.cnet> <20170116180147.GD31452@potion> <20170116193655.GA7649@amt.cnet> <20170116194715.GA8017@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Richard Cochran To: Radim Krcmar , Miroslav Lichvar Return-path: Content-Disposition: inline In-Reply-To: <20170116194715.GA8017@amt.cnet> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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