[ntp:questions] Re: Clock drift problems

Michael Black et472 at FreeNet.Carleton.CA
Mon Jan 19 12:30:19 UTC 2004

Christopher Browne (cbbrowne at acm.org) writes:
> Oops! allancady at yahoo.com (Allan Cady) was seen spray-painting on a wall:
>[stuff deleted] 
>> The explanation I'm given about why the clock is losing time so
>> badly in the first place (about 15 minutes a week), is that it
>> happens when we do our weekly backups to DVD-ROM; something is
>> locking out the hardware interrupt that makes the clock work.  Is
>> this "normal"?  They claim it's nothing to do with Linux, that it
>> would happen with Windows too.  I've never seen anything like this
>> happen on Windows... DOS maybe, but that was 15 years ago.  This is
>> a Dell PowerEdge 1600 machine, less than a year old.
> Yeah, this is something of a "known issue."  When the system bus gets
> taken over by DMA, that certainly can block clocks' access.  Various
> Unixes have suffered from similar things over the years, although it
> is usually just that the clock gets jittery, not that it outright
> dies.
Well, it's really because time is kept with the real time clock.
In the original IBM PC, you had to set the time and date every time
you turned on the computer.  Soon after, you could get boards that
kept time, running even when the computer was turned off.  When the AT
came along, the clock was built into the computer.  But, this clock was
only read when turning on the computer (unless one deliberately read it at
other times).  However accurate that clock might be set (and however well
it keeps the proper time) unless it's being read regularly, the real time
clock will drift away from it.  And the longer the RTC runs without
reading the hardware clock, the greater the accumulated error.

The Real Time Clock is of course counting interrupts.  Something with
a presumably accurate timing sends an interrupt to the CPU on a regular
basis, and software keeps track of those interrupts.  If, for whatever
reason, the CPU can't handle the interrupt when needed, because
it's doing something that requires no interrupts or because a higher
priority interrupt comes along, the CPU will not count that interrupt,
and it will lose a tiny fraction of time.  Do this often enough, or for long
enough, and you end up with quite an accumulated number of misses, which
translates to a slow clock.

If the computer was turned off each night, there would be a finite time
that the RTC could drift from the hardware clock in this way.  But if
you leave something on for months and months, there is no resetting to
hardware time.

Obviously, the solution is to regularly resync the RTC to the hardware
clock, or to some time standard on the net.  Do it regularly enough,
and there will not be too much accumulated drift.


More information about the questions mailing list