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.
--
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
