|
Note: The following paper was presented at PTTI '92 in McLean, Virginia, USA on 1992 December 2. The 24th
Annual Precise Time and Time Interval Applications and Planning Meeting was held at the Ritz-Carlton Hotel
at Tysons Corner. The major emphasis was on systems that use time, time interval and frequency and that
are not generally known or thought of as timed systems. These include PTTI applications in major aerospace,
military, commercial and telecommunications programs. The meeting is sponsored each year by the United
States Naval Observatory Directorate of Time, and is currently chaired by Mrs. Sheila C. Faulkner (202/653-1460).
RighTime tm A Real Time Clock Correcting Program For MS-DOS-Based Computer Systems
G. Thomas Becker
Air System Technologies, Inc.
14232 Marsh Lane, Suite 339
Dallas, Texas 75234-3899
500/448-9660
500/448-9661 Fax
500/673-4625 BBS
GTBecker@RighTime.Com
http://rampages.onramp.net/~gtbecker
Abstract
A computer program is described which effectively eliminates the misgivings of the DOS system clock in
PC/AT-class computers. RighTime is a small, sophisticated memory-resident program that automatically corrects
both the DOS system clock and the hardware "CMOS" real time clock (RTC) in real time. RighTime
learns what corrections are required without operator interaction beyond the occasional accurate time
set. Both warm (power on) and cool (power off) errors are corrected, usually yielding better than one
part per million accuracy in the typical desktop computer with no additional hardware, and RighTime increases
the system clock resolution from approximately 0.0549 second to 0.01 second. Program tools are also available
which allow visualization of RighTime's actions, verification of its performance, display of its history
log, and which provide data for graphing of the system clock behavior. The program has found application
in a wide variety of industries, including astronomy, satellite tracking, communications, broadcasting,
transportation, public utilities, manufacturing, medicine and the military.
Table of Contents
Most MS-DOS, PC-DOS and DRDOS users have long ago learned to live with, and generally regard as inadequate,
the system time-of-day clock that is a standard component of these operating systems. The typical DOS-based
computer system clock exhibits inaccuracies that can range from a few seconds to several minutes per day,
and the system can lose track of days at a time (on Friday, leave a DOS-based computer running at the
office and go home for the weekend; when you return to the office Monday morning, the machine will very
likely tell you it's Saturday). These errors are the result of a combination of compromises at several
steps in the IBM PC design process, circa 1980. The consequences remain with users to this day.
No autonomous RTC hardware was implemented in the original IBM PC announced in August, 1981. Instead,
software (partially in ROM-based BIOS firmware and partially in RAM-resident DOS) counted regular interrupts
which were generated by an interval timer. DOS converted the resulting "tick" count to conventional
expressions of time of day when application software called for it, and, if during a request for the time
DOS determined that midnight had passed, it incremented the system date. Whenever the system was booted,
the date and time was initialized to 1980-01-01 00:00:00; the user was expected to set both at each boot.
With the introduction of the PC/AT in August, 1984, a hardware clock system - a Motorola MC146818 CMOS
RTC and some associated circuitry - was included. The part was powered by a battery when the system was
not operating so it would maintain date and time continually. Released at the same time, DOS Version 3
automatically read the CMOS RTC clock date and time at system boot and set its date and tick counts to
match; aside from that initialization at boot, the hardware clock was not used. When the DOS date or time
was changed by the user, the change was not reflected in the CMOS RTC clock; it needed a separate setup
utility program. Later DOS versions set the CMOS RTC clock at the same time the DOS clock was set, but
the CMOS RTC clock time was still read, and is still today, only at boot.
No other changes have been made to the time-of-day clock mechanisms of the AT-class PC-compatible computer
since 1984, except as have been applied to the CMOS RTC clock hardware itself. (Dallas Semiconductor,
Motorola and others now produce several compatible lithium-powered clock modules and Intel and semiconductor
producers have incorporated the RTC logic within large-scale integrated circuits that support the current
microprocessors.) The hardware manufacturers and software publishers moved on as if whatever few difficulties
that existed were solved with the advent of the PC/AT. The problems were neither solved nor few.
The interval timer that DOS uses to generate the regular tick that it counts is driven by an uncalibrated,
unconditioned and usually non-adjustable 1.193 Mhz source (1.193 Mhz is one quarter of the original PC
system clock frequency of 4.77 Mhz, and it is also one third of the NTSC television standard color burst
frequency, 3.579 Mhz). The interval timer is programmed to divide that frequency by 65,536 to produce
an interrupt rate of approximately 18.206 ticks per second which determines the resolution of the standard
DOS clock, approximately 54.925 milliseconds. DOS allows for the expression of time in 0.01 second increments,
but it cannot internally maintain that resolution nor represent decimal times exactly due to the tick
resolution.
DOS depends upon the cooperation of all software that runs on the machine to allow sufficient time for
each interval timer tick interrupt to be counted. This is not always possible, so some interrupts are
missed and are not counted. On a computer whose interrupt system is heavily loaded, the accumulation of
lost interrupts makes the DOS clock appear to run slowly.
The tick interrupt is normally intercepted by a routine in the ROM BIOS which increments a 32-bit tick
count in RAM and determines if a value that represents approximately 24 hours has been exceeded (the tick
duration makes 24 hours indeterminable exactly). If so, the tick count is set to zero and a single bit
flag, representing the passing of midnight, is set and provided to DOS when it next asks for the tick
count. These DOS requests only occur when the system is in need of the current time of day. At that time,
if the bit is set, DOS increments the date. If more than 24 hours have elapsed between two requests for
time of day, DOS is unable to recognize that more than one midnight has passed. If the user displays the
date after a system has been running, but idle for more than a day, DOS will indicate that the date is
one day after the last day the machine was used.
The interval timer has found itself reprogrammed by a number of applications, usually games that require
dynamic video presentations. In these programs, the interrupt that the interval timer yields is used to
refresh the video screen at a high rate. At the termination of the game, the DOS clock is rarely where
it should be. Some of the more responsible programs make an attempt at resetting the DOS clock to compensate
for the game session duration, but others leave it in disarray. If the game increased the tick rate and
left the intercepting BIOS interrupt "hook" in place, the DOS clock will have advanced greatly;
in the worst examples, the rate is left accelerated as well.
DOS will properly increment the date that it maintains if the machine is running at 2000-01-01 00:00:00
but DOS will not make the century change in the CMOS RTC. For as long as the machine continues to run
through and after that date the DOS date will be correct, but at the first reboot after 2000-01-01 00:00:00
the CMOS RTC will supply the apparent date of 1900-01-01 to DOS; this is an invalid date to DOS, which
internally represents dates as days-since-1980-01-01, so the DOS date oddly will become 1980-01-04.
The CMOS RTC clock resolves only to whole seconds. When DOS reads it at boot, one second of ambiguity
is set in the DOS clock even if the CMOS RTC clock is accurate. Conversely, when the DOS clock is set,
DOS transfers whole seconds to the CMOS RTC clock but makes no attempt to deal with the fractional part
of the seconds, nor does it synchronize the seconds transition, so even if the DOS clock is set accurately,
the CMOS RTC clock won't be.
The CMOS RTC clock is usually paced by a 32.768 Khz quartz crystal which is loaded by a pair of capacitors.
The crystal is often an inexpensive watch-type device, characterized for operation at room temperature
(typically 25 degrees C). At temperatures either above or below the characterized temperature, the crystal's
resonance change will slow the clock. The loading capacitors are generally not temperature compensated
and add to the detuning. Except in the case of the modern CMOS RTC modules mentioned earlier, no provision
is made to allow trimming the crystal frequency. Dallas Semiconductor RTC modules are internally trimmed
at the factory to +20 seconds per month at room temperature, anticipating an environment that will slow
the clock; in use, the computer system internal temperature is widely varying, ranging from perhaps 10
degrees C when the system is not powered to 55 degrees C when it is. Dallas Semiconductor's data indicates
that the part can be expected to run as much as 2.5 minutes per month slow at these temperatures.
The CMOS RTC clock oscillator is powered by the system's +5 volt supply when the machine is powered and
by a lower voltage when it is on battery backup. Typically, an additional six parts per million error
can be expected when the clock is running on battery power.
The CMOS RTC clock part provides an option that will automatically advance or retard the time at 0200
on the appropriate Sunday morning when Daylight Savings Time and Standard Time, respectively, start in
the USA. This feature is usually not used, since no mechanism to invoke it exists in DOS. DOS does, nevertheless,
include a bit in its internal time data structure that indicates whether this automatic time change feature
is enabled or not (many documents incorrectly state that the bit indicates that the time is Daylight Savings
Time). The rule was changed in 1986 and many computers - even current models - contain parts that still
adopt the pre-1986 rule. Even if the feature is enabled, many machines will change on the wrong Sunday
morning in April (the last rather than the first). Dallas Semiconductor's DS1287 RTC module was introduced
with the currently correct rule. Motorola corrected its part with the announcement of the MCCS146818B1M
RTC module in 1991.
The CMOS RTC hardware maintains a two-digit year. The century is not automatically incremented when the
year overflows from 99 to 00, so the unfortunate result is that 2000-01-01 00:00:00 will appear to be
1900-01-01 00:00:00 in the CMOS RTC. Current BIOSs set and read the century, but don't maintain it. Some
BIOSs will substitute 1980 for the out-of-range 1900 date.
The Solution to the Problems
RighTime approaches the solution to these problems by making best use of the better qualities of each
of the two clocks. Two foremost qualities of the CMOS RTC are its relative stability and its autonomy.
The DOS clock has a high resolution interval timer available to it, although its availability is conditional,
subject to loss of power and to software that commandeers it.
With these resources, RighTime does four fundamental things:
-
RighTime slaves the DOS clock to the CMOS RTC, frequently referring the DOS date, tick count and interval
timer count to the CMOS RTC date and time;
-
RighTime operates the interval timer in a disciplined mode that allows deriving a higher resolution than
standard while maintaining the standard tick rate and count for compatibility;
-
RighTime maintains accuracy by regularly calculating and applying corrections to the DOS clock and adjustments
to the CMOS RTC; and
-
RighTime intercepts and monitors time set commands to learn and refine the CMOS RTC correction rate.
RighTime is loaded each time DOS is booted, makes itself resident in system memory, and hooks a number
of system interrupts. (A hook is a logical tap in the execution chain of some specific event or class
of events.) For its time-keeping tasks, RighTime hooks an interrupt from the CMOS RTC, one from the interval
timer, and several that convey the time set and read commands from an application program or the user
to DOS. Other interrupts are intercepted to disallow functions that could otherwise change resources that
RighTime must exclusively control. Since DOS is not ordinarily a multitasking operating system, several
other interrupts are hooked to determine when system activities are momentarily idle. These logical pauses
are often very brief, but occur frequently and allow RighTime to do its manipulations as a transparent
background function without noticeably affecting work that is ongoing in the foreground.
The CMOS RTC is programmed to produce an interrupt once per second, immediately after its internal seconds
update. Every four seconds, RighTime reads the CMOS RTC date and time, calculates the equivalent DOS clock
values, and sets the tick count and interval timer count and mode accordingly. This regular update prevents
the DOS clock from wandering far from the CMOS RTC time and corrects whatever ills might come from a game
or other application that reprograms the interval timer. Between these periodic updates, the DOS tick
count is incremented by the BIOS interval timer interrupt handler - just as it is without RighTime - and
is available to those programs that use the tick count directly.
RighTime augments the routines that handle the conversions of tick count to time-of-day and time-of-day
to tick count with its own routines. These routines process the Get DOS Time and Set DOS Time functions,
respectively, and provide resolution that far exceeds the 0.01 second resolution of the DOS clock data
structure. Any program that gets the time via the DOS calls will benefit from the additional resolution
that RighTime provides.
Although the CMOS RTC is relatively stable, its rate is rarely highly accurate. Since, under RighTime,
the DOS clock mimics the CMOS RTC, the DOS clock would exhibit the same rate error unless corrected. RighTime
handles this by incorporating a calculated correcting offset in each of the DOS clock updates. The result
is a deliberately increasing divergence of the two clocks. Assuming that the corrected DOS clock rate
is accurate, the CMOS RTC must be occasionally adjusted to match the DOS clock. The CMOS RTC is advanced
or retarded when the difference between the two clocks has reached one second; the DOS clock offset is
adjusted accordingly. If the DOS clock is set to the correct time, and the CMOS RTC rate correction is
proper, the result is a DOS clock whose expression is within 0.01 second of the correct time and a CMOS
RTC that is within one second of the correct time. Actually, the calculated DOS clock offset is bipolar,
so the CMOS RTC is never more than +/-0.5 second from the correct time.
Since the CMOS RTC rate can vary with changes in temperature and voltage, the theoretically perfect correcting
algorithm would account for both in appropriate complex terms. In practice, two rates are maintained by
RighTime, and suffice; one represents the system power-off state and the other represents power-on. We
refer to them as "cool" and "warm", though, since most users seem intuitively familiar
with temperature effects. RighTime applies a single calculated adjustment when it is loaded at system
boot that corrects for CMOS RTC error that accumulated while the system was in the power-off state; if
the program has not been running for more than 30 minutes, the cool correction rate is employed, otherwise
the warm correction rate is applied. With that exception, the warm correction rate is used in each DOS
clock update.
The CMOS RTC rate correction values are learned. RighTime assumes that whenever the DOS clock is set,
it is set accurately. At the moment of set, then, the existing DOS clock error is a function of the CMOS
RTC rate error, the current cool and warm correction rates, the time elapsed since the last accurate time
set, and the ratio of warm and cool operation in that period. The correction rates are refined with each
time set, yielding decreasing error as they close on the "ideal" values. These values, and others
that are necessary for the process, are stored in a suitable place within the machine hardware or in a
small dedicated file.
RighTime will assure that the CMOS RTC century byte is correctly maintained, in turn providing DOS with
a correct date at boots following 2000-01-01 whether or not the machine was running at that time.
For those users who want one less clock to change twice each year, RighTime offers support for the American
Daylight/Standard time change feature of the CMOS RTC. Since the change itself is handled by the hardware,
the program does not need to be running when the change needs to occur. The user is cautioned, though,
that the change might not occur on the prescribed day in April due to an outdated hardware component.
Although RighTime can usually be used effectively with the defaults, the program accepts a wealth of options
and user-provided parameters that can detail the function to a specific machine environment, and a logical
interface is included that allows the time setting functions to be automated. A system can be easily designed
that will continually adjust itself to a slowly changing operational environment as might be encountered
with seasonal temperature changes at a remote data acquisition site.
RighTime is an effective software solution to the poor time-keeping performance of the PC/AT-compatible,
DOS-based computer system. The cesium beam and hydrogen maser clock industries will remain unchallenged
by your computer, but it should be easy to achieve error rates of 0.5 second per week or better. We regularly
hear reports of one tenth of that error rate from stable systems, but these represent the best that can
be expected in the current form of the program. The current version requires only 6.5K of RAM, and the
program can be loaded into high memory.
An evaluation copy of RighTime is available electronically on the Air System Technologies BBS free of
charge. The evaluation program is fully functional and may be used for up to 30 days.
-.-
/ Time Software
|