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. | ============================================================================ =
