linux-mips
[Top] [All Lists]

Re: CVS Update@linus.linux.sgi.com: linux

To: ralf@uni-koblenz.de
Subject: Re: CVS Update@linus.linux.sgi.com: linux
From: "William J. Earl" <wje@fir.engr.sgi.com>
Date: Wed, 11 Mar 1998 15:37:40 -0800
Cc: "William J. Earl" <wje@fir.engr.sgi.com>, linux@cthulhu.engr.sgi.com
In-reply-to: <19980311231239.11868@uni-koblenz.de>
References: <199803111521.HAA27172@linus.linux.sgi.com> <199803111755.JAA14604@fir.engr.sgi.com> <19980311231239.11868@uni-koblenz.de>
Sender: owner-linux@cthulhu.engr.sgi.com
ralf@uni-koblenz.de writes:
 > 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
broken.

 > 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).

<Prev in Thread] Current Thread [Next in Thread>