NTP

[tmetro-blu-5a1Jt6qxUNc at public.gmane.org (Tom Metro)]

Richard Pieri wrote:
> Tom Metro wrote:
>> I thought ntpd stepped the time if there was a large delta.
>> (According to /etc/default/ntp the -g option is being specified,
>> which is supposed to permit nptd to make large steps when initially
>> started.)
> 
> -g is the sanity check.  If the system time is more than -g's value  
> off (default 1000 seconds) then ntpd says "see ya!" and quits.   
> Setting it to 0 should prevent ntpd from quitting.

Setting it to 0? It doesn't appear to take a parameter. The man page says:

   -g  Normally, ntpd exits with a message to the system log if the off-
       set exceeds the panic threshold, which  is  1000  s  by  default.
       This  option  allows  the  time  to  be  set to any value without
       restriction; however, this can happen only once.  If the  thresh-
       old  is exceeded after that, ntpd will exit with a message to the
       system log.  This option can be used with the -q and -x  options.

So without -g, if delta > 1000s it bails. With it, it accepts the big 
change, but only once.

It does match my observation that ntpd kept running, it just didn't step 
the time, as expected, however, -g doesn't address the step vs. slew 
issue, only whether the process considers it a fatal situation.

-x is suggested as the way to address the step vs. slew, but the wording 
for that switch is convoluted:

   -x  Normally, the time is slewed if the offset is less than the  step
       threshold,  which  is 128 ms by default, and stepped if above the
       threshold. ...

OK, so that should mean that without -x, a delta greater than 128 ms 
will result in a step. That sounds fine, as a big delta (thousands of 
seconds) qualifies, and I want it to step, so I shouldn't need to 
specify -x, yet this doesn't match the observed behavior.

It goes on:

       ...        This option sets the threshold to  600  s,  which  is
       well within the accuracy window to set the clock manually.

So specifying -x makes ntpd *less* likely to step the time. That's not 
what I want, but besides, the delta I experiences was hours, so even if 
this switch was specified, it still should have stepped the setting.


> running ntpdate...accomplishes the same thing but does it  
> much faster. 

The ntpd man page says:

   -q  Exit  the  ntpd just after the first time the clock is set.  This
       behavior mimics that of the  ntpdate  program,  which  is  to  be
       retired.   The  -g  and  -x options can be used with this option.

So they're suggesting that:
ntpd -q -g

emulates the behavior of ntpdate, but I'm skeptical. Maybe this ntpd is 
buggy?


> ntpdate sets the time now whereas ntpd with a large  
> clock skew will take a while to sync up.

If the delta is large enough, both should do the same thing effectively, 
(with of course ntpd saying running as a daemon and ntpdate exiting).

The ntpdate man page says:

   Time  adjustments  are  made  by  ntpdate in one of two ways. If
   ntpdate determines the clock is in error more than 0.5  second  it
   will  simply  step the time by calling the system settimeofday()
   routine. If the error is less than 0.5 seconds, it will slew the time
   by  calling  the  system adjtime()  routine.

So again there is a threshold, but in this case it is 1/2 second.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/