On 8 Feb 99, at 15:35, Earl Truss wrote:

> I've been asked to explain why the current time shown in many
> applications is often so far off from a wall clock - often losing or
> gaining several seconds a day.  I was wondering if someone could
> point me in the direction for a fairly technical reference.
>
> I once read a magazine article about this but can no longer find it.
>  It was written in DOS days and I believe their primary reason was
> because the PC reads the current time from the real-time,
> battery-backed-up clock at startup but then the operating system
> maintains the time from the timer interrupt which is unreliable.
> Here's where my memory fails me.  Could someone fill in the gaps ...
> Why is this interrupt unreliable?  Is it a matter of the clock signal
> varying or is it just poorly synchronized with real-time?  Where do
> the clock signals for the various components - CPU, bus, real-time
> clock, etc. - come from?  I don't have an extensive background in
> basic electronics but do know quite a bit about the theory of how a
> computer works at this level.  I think I could understand a pretty
> detailed discussion of this.  I'd really appreciate it if someone
> could help me out in the next couple of days.  Thanks.

  There are at least three phenomena that could be relevant here.

1.  The BIOS initializes the system clock from the real-time clock.
  If the manufacturer cut some corners and used an unbuffered clock,
the value retrieved by not be valid, and the BIOS must re-try until a
valid value is retrieved.  The routine that determines whether the
value is valid could be buggy -- there are concerns that in some BIOSes
it may not be Y2K-compliant, but that's an extreme example.

2.  Interrupt latency.
  When a piece of hardware needs attention, it signals an IRQ line to
the CPU.  A programmable timer in the PC is set to do this every 55ms,
and on receipt of this signal the OS should increment the system time
counter.  The problem is that if the CPU, for whatever reason, can't
set aside other work and respond within 55ms, the timer will attempt to
signal the line again.  Because of the way the ISA bus worked, the CPU
would see these as a single "tick".
  This is less of a problem than it used to be, because CPUs are faster
and less software needs to -- or is allowed to -- interfere with the
servicing of IRQs.

3.  Power Management
  Responding to an IRQ requires that the CPU be powered up.  So when a
machine has gone into a low-power/standby mode, the system time stops
ticking.  The real-time clock, with its battery pack, continues,
though, and the support for power management in *current* OSes will re-
read the time (see #1...) when resuming from a low-power mode.  Some
earlier OS versions didn't do this, or not automatically.


David G

                         PCBUILD's List Owner's:
                      Bob Wright<[log in to unmask]>
                        Drew Dunn<[log in to unmask]>