From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941285AbdAJOaY (ORCPT ); Tue, 10 Jan 2017 09:30:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24961 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755645AbdAJOaV (ORCPT ); Tue, 10 Jan 2017 09:30:21 -0500 From: Vitaly Kuznetsov To: Thomas Gleixner Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , John Stultz , Alex Ng , Stephen Hemminger Subject: Re: [PATCH v2 0/4] hv_util: adjust system time smoothly References: <20170104172439.19683-1-vkuznets@redhat.com> Date: Tue, 10 Jan 2017 15:30:18 +0100 In-Reply-To: (Thomas Gleixner's message of "Mon, 9 Jan 2017 22:27:44 +0100 (CET)") Message-ID: <878tqj6l8l.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 10 Jan 2017 14:30:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thomas Gleixner writes: > On Wed, 4 Jan 2017, Vitaly Kuznetsov wrote: > >> Changes since v1: >> - do do_settimeofday64() when ICTIMESYNCFLAG_SYNC flag is present in the >> request (Alex Ng) >> - add pr_debug() for the case when do_adjtimex() fails (Alex Ng) >> >> Original description: >> >> 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 client is run in parallel things may go south, e.g. when >> an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY >> the Hyper-V module will not see this changes and time will oscillate and >> never converge. >> - Systemd starts annoying you by printing "Time has been changed" every 5 >> seconds to the system log. >> >> With this series I suggest to use do_adjtimex() to adjust time. My tests >> show that such method gives equally good time convergence but avoids all >> the drawbacks described above. > > To be honest, I think all of this is just tinkering. > Thank you for your comments, Thomas, > 1) do_adjtimex() is assuming that there is a single client connected which > is responsible for the updates. So I seriously doubt that a NTP client > running in the guest will cooperate nicely with that timesync magic > under all circumstances. True, as Stephen suggested we'll probably need a way to inform (or block) the second NTP client about the ongoing timesync. > > 2) There is still the possibility to force do_settimeofday() calls which > will upset NTP clients and have other side effects. > > Why is this call necessary at all? Just because it's in some spec? ICTIMESYNCFLAG_SYNC flag, demanding us to do so, is only set on the first packet (when our VM boots) and after suspend/resume/migration events. In these cases guest's time can be off by minutes/hours and do_settimeofday() is probably justified. > > 3) What happens if you have a PTP capable network card mapped into your > guest and the guest uses PTP for time synchronization? The outcome is > predictible: CRAP. > > I can see the value for a host wide time synchronization, but please use > mechanisms which do not interfere with the rest of the time eco system in > Linux. > > The timesync thing happens periodically every 5 seconds, which you can feed > nicely into the PPS subsystem and then the guest side NTP daemon can > utilize it (or not). > My understanding is that we have no guarantees from the host that these messages are sent every 5 seconds and even when they are the interval is not very precise. We can probably create a 'fake' pps signal out of these messages (e.g. these messages will just be adjusting the frequency of the signal. I can play with such approach if you think this is the way to go. -- Vitaly