: I understand that, at lease in R3.2v4.2, the real time clock does not have
: the highest software priority level, and loses timer ticks to modules
: that do resulting in time loss. In my situation, it amounts to tens of
: minutes per day. In order to remedy the problem, I removed the cron job
: that synchronizes the hardware clock with the software clock, and replaced
: it with a command that would synchronize the software clock from the
: hardware clock, because I believed the hardware clock to be more reliable.
: Something I had checked, in fact. The clock, however, still loses time.
The first step to solving a problem is to blame someone or something.
Assume that the hardware clock you checked really is more
"accurate" than the software clock and that there really
is 10 minutes of slippage per day. Let's say that you
update the software clock from the hardware clock once an
hour. Therefore, any cron script, /bin/time, sleep, or
kernel timing loop will get trashed once per hour. Your
timing will literally be garbage once per hour. This is
why the default cron script for root updates the harware
clock from the software (system) clock. No jogs.
Since you've discovered that the hardware clock is apparently
just as "innacurate" as your software clock, it would be interesting
to assign blame (if any) before proceeding. I inscribed this
script for the occasion.
echo " Month Day Hr Min Sec Year"
echo "From CMOS clk: \c"
bleh=`/etc/cmos 8 | cut -d" " -f2; /etc/cmos 7 | cut -d" " -f2; \
/etc/cmos 4 | cut -d" " -f2; /etc/cmos 2 | cut -d" " -f2; \
/etc/cmos 0 | cut -d" " -f2; /etc/cmos 9 | cut -d" " -f2`
echo "Software Time: \c"
date '+%m %d %H %M %S %y'
echo "Hardware Time: \c"
This will display both the hardware and software times continuously.
If your machine acts like mine (3.2v4.2), they will be identical all
day long. The hardware clock and the software clock are very close
to synchronized and there is no slippage. I just beatup my OSR5 box
with lots of disk, tape, swapping and cpu activity. No clock slip.
This would be a good time to test if your motherboard clock oscillator
is off frequency. The easiest way it to just take the system offline
for a day, boot MSDOS, and let it sit doing nothing more than staring
at the dos prompt. After 24 hours, run the DATE command. If it's
off, it's your motherboard clock RTC oscillator. If not, then Unix
is doing something to the time.
The clock frequency is controlled by a 32.768KHz crystal oscillator.
The basic accuracy over temperature (-10C to +60C) is +/-200 ppm.
Looking at the schematic, I'll give the oscillator an additional
+/-200ppm of drift. If the circuit uses a 14069UB inverter as an
oscillator, it will also drift with power supply voltage (which is
not an issue with a Unix box that remains on all the time). The
+/-400E-6 * 60 min/hr * 24 hrs/day = +/- 0.58min/day. Therefore,
it's probably NOT the crystal oscillator (unless it's totally
So where does time fly to? I dunno. Stealing or missing IRQ's
should not cause the hardware clock to slow down, only the software
clock. Yet they both seem to slow down simultaneously. The
software clock counts timer ticks while the hardware clock reads
the real time clock registers. Whatever is going on seems to
affect both mechanisms simultaneously.
[x] Email to author [ ] To mailing list [x] Posted to newsgroup
# Jeff Liebermann Liebermann Design 150 Felker St #D Santa Cruz CA 95060
# 408.699.0483 digital_pager 73557,2074 cis [don't]