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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
