[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 

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. 
Override the priority limit set by the operating system. Not recommended
for sissies. 
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.                              |

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]