ntpdate

[Jonathan Chen]

On Wed, Nov 16, 2005 at 12:09:45PM -0500, Chuck Swiger wrote:

[...]
> Running "ntpdate -b" at boot to forcibly syncronize the clock is a pretty 
> good idea, but you actually can convince ntpd to sync even a clock which is 
> badly off via:
> 
>      -g      Normally, ntpd exits if the offset exceeds the sanity limit,
>              which is 1000 s by default.  If the sanity limit is set to 
>              zero,
>              no sanity checking is performed and any offset is acceptable.
>              This option overrides the limit and allows the time to be set 
>              to
>              any value without restriction; however, this can happen only
>              once.  After that, ntpd will exit if the limit is exceeded.  
>              This
>              option can be used with the -q option.

The advantage of `ntpdate' vs `ntpd -g' is that ntpdate does it
_immediately_, whereas `ntpd -g' takes a bit of time before it decides
which server to sync to. This means that if your clock is out by
hours/days, there will be a period of 3-7 minutes after you boot where
your system time is badly incorrect, and then you have this big skip
when it corrects.

This could be a problem if you've got overanxious users running
`make' and other time sensitive programs almost immediately after boot;
not to mention weird skips in your various log files.

Cheers.
-- 
Jonathan Chen <jonc at chen.org.nz>
----------------------------------------------------------------------
                "If everything's under control, you're going too slow"
                                                      - Mario Andretti