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