Richard B. Gilbert
rgilbert88 at comcast.net
Mon Nov 27 20:35:37 UTC 2006
> Hal Murray wrote:
>>> It doesn't require reboots - just shutting down daily when I am not
>>> using the machine.
>> That's a slightly(?) ugly case for keeping time.
>> The problem is that the frequency of the crystal is strongly(?)
>> temperature dependent. If you run the machine for a while
>> it warms up and gets the drift file setup for that temperture.
>> When you turn it off, it cools down. When you reboot it, the drift
>> file is slightly(?) misleading.
>> How much do you care about how accurate your clock is?
> Just a normal user trying to keep a somewhat accurate clock. If left
> alone, the h/w clock can drift as much as 5 minutes in 6 months. I'm
> just trying to keep it a little more accurate than the wall clock
> running off the frequency of the local power grid.
> I finally learned about ntpd about a week ago. It had been set to run by
> the FC 5 installation. But the firewall prevented synch. When I finally
> got that worked out, my boot time went from about 1 minute to many
> minutes. In watching the boot messages, I discovered that ntpd was the
> culprit. It takes ntpd several minutes to synch during boot. Was simply
> trying to get that synch time down to something under 1 minute. During
> the time I was trying to get ntpd through the firewall, someone on this
> newsgroup mentioned using iburst to get the synch time from minutes to
> seconds. Guess they had that wrong or we used different definitions of
> So I guess if I want to use ntpd, I will have to live with the mnay
> minute boot time??
Please don't top post.
It's not clear if you are talking about the time required to boot your
system or the time required to bring your clock into reasonably tight
synchronization. Does your system wait for synchronization before
before allowing you to run applications? If so, that's something built
into your system startup and you may be able to modify the startup
scripts to avoid it.
Normally, ntpd should have little effect on the boot time.
As you are using it, it will take some time, perhaps as much as thirty
minutes, to achieve good (within +/- 20 milliseconds) synchronization.
Both the protocol and the software were intended for full time use and
work best when so used.
More information about the questions