> On Wed, Mar 11, 1998 at 09:55:38AM -0800, William J. Earl wrote:
> > Ralf Baechle writes:
> > ...
> > > o The calculated values for r4k_offset are still off by ~480
> > from the
> > > theoretical values. That means we're going to loose about 46 s
> > per
> > > day. Are the crystals that bad or is there still a bug hidden
> > > somewhere? Maybe an option to set r4k_offset to a user supplied
> > > value might help?
> > ...
> > The crystals may well be off from exactly 100 MHZ. Since the
> > frequency is high, a small percentage error adds up over a long
> > period. I believe that the crystals for the CPU clock are chosen for
> > stability, not for highly accurate specific frequency (unlike, say,
> > the crystal in a watch). You pretty much have to calibrate the CPU
> > clock using the Dallas calendar clock. The intent in IRIX, although
> > sometimes broken, is to use the Dallas clock to correct drift in the
> > CPU clock, if an external time base (via NTP or the like) is not
> > being used.
> The question is whether the Dallas chip or the i8254 timer has the more
> accurate clock. A couple of the Dallas chips I've seen are so bad that
> xntp would not be able to sync via NTP, so the i8454 clock seems to be
> preferable as the clock source. Another thing is that when using NTP
> Linux uses the software clock in the kernel and writes that time regularly
> back into the CMOS.
Yes, when using NTP, updating the CMOS from the kernel is the right
thing to do; IRIX is also supposed to do that, although that is also sometimes
> Afaik the limit for synchronisation via xntp / NTP is a failsynchronisation
> between the two clocks of about 300ppm. The current Linux kernel is at
> about 500ppm on my Indy and I sometimes see xntpd loosing synchronisation
> on the Indy. I haven't researched this but I suppose the software PLL in
> xntpd ``unlocks'' now and then.
If the Dallas is drifting much more than a cheap digital watch,
it is probably sick, especially if the drift is most pronounced when the
system is powered off. I have seen both Indys and PCs with that problem
(including my 486 notebook running linux).