Message-ID: <871svtybqb.fsf@vitty.brq.redhat.com>
Date:   Mon, 23 Jan 2017 17:36:44 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Radim Krcmar <rkrcmar@...hat.com>
Cc:     devel@...uxdriverproject.org, Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        John Stultz <john.stultz@...aro.org>,
        Alex Ng <alexng@...rosoft.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Olaf Hering <olaf@...fle.de>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH v4 2/2] hv_utils: implement Hyper-V PTP source

Radim Krcmar <rkrcmar@...hat.com> writes:

> 2017-01-19 15:16+0100, Vitaly Kuznetsov:
>> With TimeSync version 4 protocol support we started updating system time
>> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
>> there is a time sample from the host which triggers do_settimeofday[64]().
>> While the time from the host is very accurate such adjustments may cause
>> issues:
>> - Time is jumping forward and backward, some applications may misbehave.
>> - In case an NTP server runs in parallel and uses something else for time
>>   sync (network, PTP,...) system time will never converge.
>> - Systemd starts annoying you by printing "Time has been changed" every 5
>>   seconds to the system log.
>> 
>> Instead of doing in-kernel time adjustments offload the work to an
>> NTP client by exposing TimeSync messages as a PTP device. Users may now
>> decide what they want to use as a source.
>> 
>> I tested the solution with chrony, the config was:
>> 
>>  refclock PHC /dev/ptp0 poll 3 precision 1e-9
>> 
>> The result I'm seeing is accurate enough, the time delta between the guest
>> and the host is almost always within [-10us, +10us], the in-kernel solution
>> was giving us comparable results.
>> 
>> I also tried implementing PPS device instead of PTP by using not currently
>> used Hyper-V synthetic timers (we use only one of four for clockevent) but
>> with PPS source only chrony wasn't able to give me the required accuracy,
>> the delta often more that 100us.
>> 
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>> ---
>
> It is a nice coincidence that KVM is working on a PTP driver as well,
> https://lkml.org/lkml/2017/1/20/247, and it uses more precise/accurate
> method of converting the host time that Hyper-V could also use.
>
> Hyper-V provides {host_time, ref_time} tuple, but gettime64() requires
> that you return just host_time and a new "ref_time" is then computed to
> be in the middle of two guest_time reads.
> I recommend you use getcrosststamp PTP callback, which allows you to
> provide the tuple.  Userspace can then use PTP_SYS_OFFSET_PRECISE
> ioctl.

Thanks, good suggestion,

as far as I see PTP_SYS_OFFSET_PRECISE support was just added to chrony:
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=31b6a14444a8f23147077df3c6a64518d082c35e

I'll implement getcrosststamp() as well but I'll probably have to wait
till K. Y.'s restructuring (https://lkml.org/lkml/2016/12/30/260) lands
and do my series on top of that. We'll also be using the TSC page
clocksource (when available) to not do the unneeded vmexit.

>
> KVM patches also proposes to change PTP_SYS_OFFSET, so when gettime64
> callback is not implemented, the ioctl uses getcrosststamp instead,
> which would avoid code duplication and improve precision/accuracy.

It's probably still worth it to have the 'lightweight' gettime64()
implementation as going through the getcrosststamp() routine (see
get_device_system_crosststamp() which we'll probably use for Hyper-V
also -- it's not very simple) every time and throwing away half of the
result doesn't look optimal.

-- 
  Vitaly

Powered by blists - more mailing lists