system clock is too slow
Gene Heskett
gene.heskett at verizon.net
Wed Jul 28 03:43:44 UTC 2004
On Tuesday 27 July 2004 19:20, Rick Stevens wrote:
[...]
>ntpdate drags your machine kicking and screaming into compliance
> with your NTP servers RIGHT NOW, while ntpd KEEPS it current. If
> ntpd has to pull the machine into compliance, it does it just a
> little bit at a time so it may take quite a while for it to get it
> synchronized. Once the clock is synched, ntpd will keep it
> synched.
>
>Think of ntpdate as a "rapid charger" on your clock, while ntpd is a
>"trickle charger". Another analogy is ntpdate is a sledge hammer
> (get the grunt work done), ntpd is a jewler's mallet (do the fine
> tuning).
>
>Ideally, you use ntpdate once (normally at boot), and have ntpd run
> in the background. That's what the startup scripts do.
Unless you are keeping your hw clock on zulu time, Rick. Then a crash
recovery sets the system clock 5 hours ahead of time because the
shutdown portion of the script wasn't run.
My solution is to make a copy of my updateclock script, which uses
'ntpdate -s -p 2' as the first argument, and a randomly selected
server from a list of nearly 40 as the second argument.
I call this one startclock, put it in rc.local and it has
'ntpdate -s -p 2' as its 1st argument. It seems to work here, and I
just did it, so on the next crash recovery reboot I do, maybe I'll
get the right time instead of 5 hours in the future, which gives gcc
a huge tummy ache.
Steven Hawking tells us thats not possible anyway :)
--
Cheers, Gene
There are 4 boxes to be used in defense of liberty.
Soap, ballot, jury, and ammo.
Please use in that order, starting now. -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004,
Maurice E. Heskett, all rights reserved.
More information about the users
mailing list