From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966454AbdAIV2A (ORCPT ); Mon, 9 Jan 2017 16:28:00 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:52421 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964970AbdAIV16 (ORCPT ); Mon, 9 Jan 2017 16:27:58 -0500 Date: Mon, 9 Jan 2017 22:27:44 +0100 (CET) From: Thomas Gleixner To: Vitaly Kuznetsov 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 In-Reply-To: <20170104172439.19683-1-vkuznets@redhat.com> Message-ID: References: <20170104172439.19683-1-vkuznets@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. 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? 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). Thanks, tglx