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.
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.
I wonder how well NTP works over a typical AX.25 link ...