On 2015-01-21, Mike Cook <michael.c...@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 <st...@ntp.org> a ??crit : >> >> Rob writes: >>> Sander Smeenk <ssme...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
