Paul writes: > On Wed, Jan 21, 2015 at 5:40 PM, Harlan Stenn <[email protected]> wrote: > >> ... 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. > > Well ... at least under Linux if ntpdate calls adjtime and then another > program calls adjtime before the first completes the result may not be what > is expected. Under SYS_WINNT ntpdate only steps.
That's not an applied update then. And even if there is an adjtime() correction going on, if the system follows the rules about the slew rate, that will still be pretty much accounted for by the t1 and t4 timestamps. If a slew adjustment is made, any under/over correction will be noticed at the 2nd packet exchange. If a step adjustment is made, that will stop any previous pending adjustment. Regardless, look at the clock state transition table to see what goes on. ntpd is about stable system time, when possible and reasonable. This is another reason to let ntpd do its job by starting it with -g and letting it run, instead of trying to outsmart it and slewing the clock before ntpd starts. H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
