Re: updating the RTC automagically

Richard B. Johnson (root@chaos.analogic.com)
Fri, 19 Nov 1999 15:08:52 -0500 (EST)


On Fri, 19 Nov 1999, Harald Koenig wrote:

> On Nov 19, Richard B. Johnson wrote:
>
> > The time-keeper (32kHz temperature-compenstated piezoelectric resonator)
> > in the RTC is much more stable than the CPU clock, which in recent
> > boards isn't even a quartz crystal, it's a cheap barium titanate
> > "Ceramic resonator".
>
> sorry but that's pure theory! I've seen quite some main boards where
> the system clock was pretty good (most likely just by acident;) and
> the RTC had frequency errors of (much) more than 100ppm...

Well let's see:

100ppm is 100 HZ/Megahertz

+/- 0.000100 for every second
There are 3600 * 24 = 86,400 seconds in a day
86,400 * 0.000100 = 8.64 seconds per day if the drift is all in
the same direction, and continuous.

The provided log showed that the system clock was typically -14 seconds
per day, roughly twice that. So it's not, as you say, "pure theory".

The instruction manual for the Motorola MC146818A Realtime clock
chip states that the clock is guaranteed to be within +/- 5 seconds
per day with a "typical" drift of +/- 2 seconds. Of course now-days,
some cheaper noname clone with a built-in battery is often used.

The "crystal" in my ASUS P2B-DS AGP Mainboard is an integrated "Clock"
chip, guaranteed to start at 2.8 volts and be able to drive 10 "ttl"
loads. There isn't even a drift specification! Generally, as a CPU
clock or PLL reference from which the CPU clock is derived, nobody
cares.

>
> > I don't think the you should set the RTC from the kernel except during
> > the following once-a-day crond script.
>
> that only depends on which quartz oszilator is worse -- you have to gamble;)
>

Well you can measure it. NIST provides a good reference that, at the
end-point, is accurate to within a second. It is derived from a clock
that has been defined to be "exact". i.e., the standard.

Cheers,
Dick Johnson

Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/