Re: [iPAQ] real-time clock accuracy

On Mon, Jun 11, 2001 at 02:20:18PM -0400, Nicolas Pitre wrote:
>
>
> On Mon, 11 Jun 2001, Jeff Sutherland wrote:
>
> > On Mon, Jun 11, 2001 at 10:59:22AM -0400, Nicolas Pitre wrote:
> > >
> > >
> > > On Mon, 11 Jun 2001, Russ Nelson wrote:
> > >
> > > > My ipaq has been up for fourteen days, and my hardware clock is now
> > > > four hours ahead of the real time of day. Is there anything to be
> > > > done about this?
> > >
> > > According to the SA1110 manual, there is a "trim" register that allows you
> > > to adjust, or compensate, for unprecise cristal clocking the RTC. However
> > > the correction is said to be at most +/-5 seconds per month.
> > >
> > >
> > > Nicolas
> >
> > But if it's been up for 14 days, it's running off the 3.6864MHz crystal,
> > no?
>
> The software maintained clock which Linux uses is based on the 3.6864MHz
> clock. The hardware RTC that survives through sleep mode is based on what
> is assumed to be a 32.768KHz clock by default. The RTC has a register to
> specify what is the real RTC clock frequency which lets you correct the
> clock error with a precision of +/- 5 sec per month.
>
>
> Nicolas

Right. But, if the kernel uptime is 14 days, and there hasn't been
an intervening 'hwclock --hctosys' somewhere, the kernel timekeeping
is based only on the CPU clock. Now, I haven't played with the
suspend/resume on this too much, but I would think that on a resume,
something has to reload the system time from the RTC. Does "up for
14 days" include periods of suspended operation? And what's the
mechanism of choice for reloading system time on resume?

-- 
  Jeff Sutherland, Accelent Systems, Inc.   <http://www.accelent.com>
  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  
Whenever I return from a trip abroad, I'm always amazed by two things:
All the wide open space we have in this country,
and how bad the roads are.