ntp won't set clock [Was clock.redhat.com question]

[Mike Bartman]

At 12:46 PM 5/18/04 +0200, Corné Beerse wrote:

>ntpd by default does not set the new 
>time but it slows or speeds the clock to get in sync. This is up to a
couple of 
>miliseconds per second. Hence 1 or 2 minutes per hour.

Except that if the required change is greater than a given amount (a few
seconds I seem to remember) it will *step* the clock, rather than *slew*
it.  If you want it to slew no matter how big the change required, you can
use the -x option to force it to always slew.  This is a very slow process,
as you say.  From the NTP ntpd web page:

"The issues should be carefully explored before deciding to use the -x
option. The maximum slew rate possible is limited to 500 parts-per-million
(PPM) as a consequence of the correctness principles on which the NTP
protocol and algorithm design are based. As a result, the local clock can
take a long time to converge to an acceptable offset, about 2,000 s for
each second the clock is outside the acceptable range."

>You should read the last line about the -p option as a hint: That realy
sets the 
>time.

Typo.  I think you meant the "-q" option.  From the same web page:

-p pidfile 
Specify the name and path to record the ntpd's process ID. 
-P 
Override the priority limit set by the operating system. Not recommended
for sissies. 
-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. 

-- Mike Bartman
=============================================================================
| I didn't really say all the things that I said.  You probably didn't read |
| what you thought you read.  Statistics show that this whole thing is more |
| than likely just a hideous misunderstanding.                              |
============================================================================
=