Disappointingly the clock is back to drifting again, so a cron job every
10 minutes it is . . .
The board in question is an Asus M2N which has been fine in all other
regards.
Roger
Roger Searle wrote:
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.
