On Mon, Jan 23, 2017 at 08:44:53PM +0100, Paolo Bonzini wrote: > > > On 23/01/2017 19:44, Richard Cochran wrote: > >> device clock |sample1P,deviceclock| |sample2P,deviceclock| > >> ------------------------------------------------------------- > >> realtime clock |sample1P,realtimeclock| |sample2P,realtimeclock| > > > > Are |sample1P,deviceclock| and |sample1P,realtimeclock| taken at the > > same instant in time? > > > > If not, then calling that PTP_SYS_OFFSET_PRECISE is misleading. > > Yes, of course. This was added for the e1000e drivers first, but chrony > isn't using it yet. In the case of KVM, the same host TSC value is used > to produce the host clock and (converted to guest TSC) the guest clock. > > If you just implement getclock64 the PTP_SYS_OFFSET output: > > device clock | |sample2| |sample4| |sample6| ... > ------------------------------------------------------------- > realtime clock |sample1| |sample3| |sample5| > > has a very large distance between samples on the same line (about 1 us), > and I think it is too noisy for userspace to make sense of the output. > > So, on one hand chrony only uses the mean of realtime clock samples, in > an attempt to produce precise cross timestamps. On the other hand, even > though KVM could produce those natively, chrony does not support > PTP_SYS_OFFSET_PRECISE. > > Marcelo's patch then produces fake realtime clock samples that, however, > let chrony derive the cross timestamps that KVM produced in the first > place. The outcome is really great accuracy compared to previous > versions of the patch, often just +/- 2 or 3 nanoseconds. > > Paolo Nope, the clock offset is the value inside square brackets. The +/- is the error. So the clock offset is actually up to 680ns. Yes for greater accuracy userspace should implement _PRECISE support. I'm resending v5 with native support for ->gettime and ->getcrosststamps.
