Harlan Stenn <st...@ntp.org> wrote: > 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.
The problem is that ntpd believes that corrections it is applying are because of frequency errors in the clock, while in this case they are because of resets done externally. During the startup phase, bad things happen anyway (like touching the carefully determined and saved drift value), doing a couple of successive restarts makes it worse because adjtime effects accumulate in the kernel without knowledge of ntpd. Applying a fixed offset outside of ntpd makes it worse. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions