From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753704AbdAROKG (ORCPT ); Wed, 18 Jan 2017 09:10:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58152 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753653AbdAROKE (ORCPT ); Wed, 18 Jan 2017 09:10:04 -0500 Subject: Re: [patch 3/3] PTP: add kvm PTP driver To: Miroslav Lichvar References: <20170116180147.GD31452@potion> <20170116193655.GA7649@amt.cnet> <20170116194715.GA8017@amt.cnet> <20170116200112.GB8739@amt.cnet> <20170117080327.GG14227@localhost> <20170117113052.GA27759@amt.cnet> <20170117153621.GE31452@potion> <20170118121738.GA14832@amt.cnet> <20170118122456.GC13762@amt.cnet> <94a761cb-8bcd-e1a6-d07e-02fedc423e33@redhat.com> <20170118133614.GK14227@localhost> Cc: Marcelo Tosatti , Radim Krcmar , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Richard Cochran From: Paolo Bonzini Message-ID: <255c35c1-4400-7e52-8cb0-bf5a344e9f74@redhat.com> Date: Wed, 18 Jan 2017 15:02:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170118133614.GK14227@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 18 Jan 2017 14:02:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/01/2017 14:36, Miroslav Lichvar wrote: > On Wed, Jan 18, 2017 at 01:46:58PM +0100, Paolo Bonzini wrote: >> On 18/01/2017 13:24, Marcelo Tosatti wrote: >>>> Testcase: run a guest and a loop sending SIGUSR1 to vcpu0 (emulating >>>> intense interrupts). Follows results: > >>>> Do you still want to drop it in favour of simplicity? > >> It's just that it's not obvious why you get better results with biased >> host timestamps. What makes the biased host timestamp more precise? >> >> I'd rather use PTP_SYS_OFFSET_PRECISE instead, but unfortunately chrony >> does not support it---but I would still prefer you to support >> PTP_SYS_OFFSET_PRECISE as well. > > Interesting. I wasn't aware that there is a new ioctl for measuring > the HW-sys offset. Adding support to chrony shouldn't be difficult. > > If I understand it correctly, PTP_SYS_OFFSET can be emulated on top of > PTP_SYS_OFFSET_PRECISE simply by copying the sys_realtime and device > fields to corresponding ts slots. The apparent delay will be zero, but > that's ok if the conversion is really accurate. Yes, for 1 sample only. Otherwise you'd have the same issue as in Marcelo's driver (the device aka guest timestamp from PTP_SYS_OFFSET_PRECISE would not be halfway between the system aka host timestamps), and your idea below could be applied. > I'm not sure if trying to do that in the opposite direction is a good > idea. An application using PTP_SYS_OFFSET_PRECISE may assume the > conversion is accurate and not include any delay/dispersion in an > estimate of the maximum error, which is needed in NTP for instance. > > If we know the host timestamp ts[1] is not in the middle between the > guests timestamps ts[0] and ts[2], but rather closer to ts[2], why not > simply shift ts[1] by (ts[2]-ts[0])/2 ? Interesting idea! For this to work, KVM needs to implement getcrosstimestamp and ptp_chardev.c can then add an alternative implementation of PTP_SYS_OFFSET, based on precise cross timestamps. Something like for (i = 0; i <= sysoff->n_samples; i++) { // ... call getcrosststamp ... sysns = ktime_to_ns(xtstamp.sys_realtime); if (i > 0) { devns = ktime_to_ns(xtstamp.device); devns -= (sysns - prev_sysns) / 2; devts = ns_to_timespec(devns); pct->sec = devts.tv_sec; pct->nsec = devts.tv_nsec; pct++; } systs = ns_to_timespec(sysns); pct->sec = ts.tv_sec; pct->nsec = ts.tv_nsec; pct++; prev_sysns = sysns; } Marcelo, can you give it a try? Thanks, Paolo