On Fri, Jan 17, 2003 at 09:57:47PM -0500, Brian Coyle wrote:
> Actually, yes. We all know that PC clocks are not accurate timepieces and
> you should (as suggested) set up NTP to sync your time.
>
> Now, as to why your clock is drifting so quickly (27 min/3 hr.), that might
> be a low/dead clock battery, a mis-calibrated crystal, bogus timer interrupts
> or any number of reasons... You still need ntp.
There are two clocks on your PC: a hardware "real time clock" (RTC), and a
software interrupt driven one. The first is a physical battery backed up
time source for when your PC is powered off. The latter is the clock you
that is maintained by the Linux kernel while the system is running.
Historically, the software clock was set to roughly 18.2Hz by a PC's BIOS.
Unfortunately, the crystal and divisor varied from vendor to vendor. The
resolution this provides is simply horrible, and thus PC software clocks
have always earned well placed scorn.
The software clock is updated 100 times a second (100Hz) on a Linux box
(the kernel resets the 18.2Hz divisor to 100Hz by default on x86
hardware). This is configurable in the kernel at compile time. It's
generally best NOT to muck with it, but some kernel patches seem to
think that setting it to 1000Hz improves the "real time performance"
of process scheduling. I've heard arguments both ways: most kernel
hackers suggest leaving it be. I tend to agree with them.
Because of the varying interrupt rates for updating your software system
clock, it's not entire accurate to begin with.
Typically, your kernel will start the software clock based on the RTC
clock as set by your BIOS, and your Linux distribution may periodically
sync up the RTC with the running software clock (keeping track of any
drift in the process). Most distributions offer network time
synchronization using ntp as well.
If you run the ntp daemon, your clock will never change drastically.
Instead, minute changes are made to the clock to drift gradually toward
the correct time. However, you may resync entirely with an external NTP
server at any time using "ntpdate clock.isc.org" (insert your NTP server of
preference here) - be sure to stop your ntp daemon before doing so then
restart it afterward.
If you run an ntp daemon, your system clock should remain relatively
accurate unless your drift rate is extreme enough to break the rate at
which ntp allows itself to change the clock gradually. In this case, I
would begin to question your kernel and hardware.
Clear? I hope so. The simple answer is that your software clock is NOT
directly tied to a hardware RTC clock. Only when you use tools like
hwclock is the RTC clock referenced or set. Otherwise it's left entirely
up to the kernel to keep track of time. Hopefully you're running a ntp
daemon to make minute clock changes over time to keep your kernel in
sync with a reasonable stratum atomic clock.
Also, remember: try not to set stratum 1 atomic clock sources in your
/etc/ntpd.conf - ask your provider for a local higher-stratum server if
at all possible. There is simply nothing wrong with a stratum 3 clock,
and it's generally considered good net etiquette not to abuse the actual
stratum 1 atomic clocks themselves.
Hope this helps.
- Ian
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 13:33:17 EDT