[ntp:questions] Timekeeping on Windows 2008r2 VM on Linux QEMU/KVM

William Unruh unruh at invalid.ca
Thu Jan 22 00:02:19 UTC 2015

On 2015-01-21, Mike Cook <michael.cook at sfr.fr> wrote:
> "Ceux qui sont pr??ts ?? abandonner une libert?? essentielle pour obtenir une petite et provisoire s??curit??, ne m??ritent ni libert?? ni s??curit??."
> Benjimin Franklin
>> Le 21 janv. 2015 ?? 23:40, Harlan Stenn <stenn at ntp.org> a ??crit :
>> Rob writes:
>>> Sander Smeenk <ssmeenk at freshdot.net> wrote:
>>>> What is actually wrong with running ntpdate to initially sync a
>>>> clock?  Why is the ntpdate.exe binary provided when 'we' shouldnt use
>>>> it?  Keep in mind that i 'just want to get to seconds accuracy'
>>>> before i start ntpd.
>>> The problem is that you give the clock an initial kick that ntpd does
>>> not know about, and it tends to have problems correcting that.
>>> This sometimes results in the problems you are seeing.
>> This sounds like total BS to me.
>> ntpd has no way of knowing what went on before it was started, and I'm
>> not aware of anything on either Windows or Unix that would cause any
>> applied immediate adjustment to have *any* residual affect on ntp.
>> But perhaps you know something I don't - please say more.
>  I don???t have a free client to test this on, but I believe that by default ntpdate will SLEW the clock if the offset is less than 128ms and that operation could still be in progress even though the command has terminated, and when ntpd is started during that period, it gets a false sense of the system clock stability as it is comparing against a moving target. I have seen this before I think, in xntpd. If it is the case, then we should see the same in unix, so I will try and test it.

I believe ntpdate simply sets the clock. No slewing. It could not, since
slewing must assume that the program is running for a while so it
can switch off the slewing. ntpdate just runs once. 

More information about the questions mailing list