I'm pleased to report that time on that box is no longer drifting. So I
won't need to implement one of these options, and will give some thought
to the "no" answer to point 1.
Thanks to everyone for their replies.
Roger
Steve Holdoway wrote:
On Wed, 19 Sep 2007 06:15:21 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
so 2 options seem to be valid:
1. if the drift is small enough between the frequent ntp restarts
then"service ntp restart" will suffice.
No. This is still incorrect.
2. "service ntp stop && ntpdate ntp.massey.ac.nz && service ntp start"
will cover drifts beyond what ever the ntp maximum adjustment is.
Yes
Do I have my head around this sufficiently now? And what is that
maximum tolerance ntp can deal with?
Roger
Steve Holdoway wrote:
On Tue, 18 Sep 2007 12:48:38 +1200
Roger Searle <[EMAIL PROTECTED]> wrote:
I'll see what date shows me tomorrow. Google tells me that some people
have resolved this issue by appending "noapic acpi=off" to grub. If I
am still getting nowhere then I believe having cron do "service ntp stop
&& service ntp start" for me a few times an hour will work.
Cheers,
Roger
No, it won't! the ntp daemon resets your local time against an external source.
This runs constantly, and is capable of a) learning how your machine's clock
drifts, and b) making small changes to keep it in step. To make large changes,
you need to use ntpdate, which is an one off process, rather than constant.
Historically, ntpdate was run once as a part of the ntpd init script, putting
the clock right on startup with ntpdate, and then keeping it correct from then
on with ntpd.
Steve.
