[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170118133614.GK14227@localhost>
Date: Wed, 18 Jan 2017 14:36:14 +0100
From: Miroslav Lichvar <mlichvar@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Marcelo Tosatti <mtosatti@...hat.com>,
Radim Krcmar <rkrcmar@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [patch 3/3] PTP: add kvm PTP driver
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.
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 ?
--
Miroslav Lichvar
Powered by blists - more mailing lists