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

Mike Cook michael.cook at sfr.fr
Wed Jan 21 23:00:30 UTC 2015


"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.


> 
> H
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list