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] > > -- > Miroslav Lichvar -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
