From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751146AbdAQPil (ORCPT ); Tue, 17 Jan 2017 10:38:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbdAQPik (ORCPT ); Tue, 17 Jan 2017 10:38:40 -0500 Date: Tue, 17 Jan 2017 16:36:21 +0100 From: Radim Krcmar To: Marcelo Tosatti Cc: Miroslav Lichvar , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Richard Cochran Subject: Re: [patch 3/3] PTP: add kvm PTP driver Message-ID: <20170117153621.GE31452@potion> References: <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> <20170116200112.GB8739@amt.cnet> <20170117080327.GG14227@localhost> <20170117113052.GA27759@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170117113052.GA27759@amt.cnet> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 17 Jan 2017 15:36:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-01-17 09:30-0200, Marcelo Tosatti: > On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote: >> On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote: >> > 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: >> > > > 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? >> >> Probably. It depends on the error of both host and guest timestamps. >> If the error is the same on both sides, it will cancel out. An >> occasional spike in the delay shouldn't be a problem as the reading >> will be filtered out, but for best accuracy it's necessary that the >> host's timestamp is taken in the middle between the guest's >> timestamps. > > The problem is that spikes can be far from occasional: it depends on activity of > the host CPU and interrupts. Whose delay can be "intermittent": as long > as interrupts are being sent to the host CPU, for example, the delay > will be high (which can last minutes). > > The TSC reading in the guest KVM PTP driver corrects for that delay. > >> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2 >> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on. >> >> ts[1] ts[3] >> Host time ---------+---------+........ >> | | >> | | >> Guest time ----+---------+---------+...... >> ts[0] ts[2] ts[4] KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes the offset very consistent, so the graph would look like: ts[1] ts[3] Host time -------------+---------+........ | | | | Guest time ----+---------+---------+...... ts[0] ts[2] ts[4] which doesn't sound good if users assume that the host reading is in the middle -- the guest time would be ahead of the host time. I'm wondering why is the PTP precision around 10ns, when the hypercall takes around 2-3k cycles. Have you measured the guest<->host offset by getting the output of the hypercall, i.e. {host_sec @ tsc, host_nsec @ tsc, tsc} and comparing it with guest time computed from the same tsc, i.e. {guest_sec @ tsc, guest_nsec @ tsc} ? Thanks.