SCO Real Time Clock - Yeah Right!

SCO Real Time Clock - Yeah Right!

Post by Mike Sham » Tue, 10 Sep 1996 04:00:00



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.

What am I missing here?

Help appreciated.

Thanks in advance.

Mike...
--
Mike Shamas

 
 
 

SCO Real Time Clock - Yeah Right!

Post by Bryan Gea » Wed, 11 Sep 1996 04:00:00



>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.
>What am I missing here?

This is a job we run every hour on the hour.

NOW1H=`date +%H`                                            
NOW1M=`date +%M`                                            
NOW2=`/etc/setclock`                                        
NOW2H=`echo "$NOW2"|cut -c 5-6`                            
NOW2M=`echo "$NOW2"|cut -c 7-8`                            
#                                                          
# Compare for hardware clock is earlier than software clock
#                                                          
if [ "$NOW2H" -le "$NOW1H" -a "$NOW2M" -le "$NOW1M" ]      
then                                                        
   echo "Software time: $NOW1H:$NOW1M"                      
   echo "Hardware time: $NOW2H:$NOW2M"                      
   echo "System time is unchanged"                          
else                                                        
   echo "Software time: $NOW1H:$NOW1M"                      
   echo "Hardware time: $NOW2H:$NOW2M"                      
   date `/etc/setclock`                                    
   echo "New software time: `date +%T`"                    
fi                                                          

It checks to see if the software clock is lagging behind the hardware
clock and if so, sets it forward. (Setting the time backwards can have
some very bad results if you're running X, certain RDB packages or
other time-sensitive pieces).

This pretty well took care of our problem. We were generally losing no
more than a minute or two per hour. However, it turned out the source
of our problem was Tuneup by Olympus Software. Its kernel driver was
eating the interrupt. Once we deinstalled it, our clock worked fine
again.

At any rate, save this script and put it in your cron so that it runs
as frequently as you need to synchronize the clocks.

 
 
 

SCO Real Time Clock - Yeah Right!

Post by Jeff Lieberma » Wed, 11 Sep 1996 04:00:00


: 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.

:


#
clear
while :
do
        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 $bleh
        echo "Software Time: \c"
        date '+%m %d %H %M %S %y'
        echo "Hardware Time: \c"
        cat /dev/clock
        echo "\n"
        sleep 5
        clear
done

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
defective).

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]

 
 
 

SCO Real Time Clock - Yeah Right!

Post by David Wooll » Sun, 29 Sep 1996 04:00:00





>> : 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.

There is no point in doing this.  The software clock is already
synchronised to the hardware clock by the kernel.  In fact, for some
applications, it is necessary to patch the kernel code to prevent this
(e.g. NTP).

Quote:>the hardware clock and system clock are very close. But the time will
>loose about 45 to 60s for each time system reboot. At first, I think may

The hardware clock only seems to be settable to minutes (at least with
SCO, possibly generally), so every reboot will lose, on average, half a
minute.

The original ten minutes a day is grossly excessive and needs
investigation.  However PC's with 500 parts per million errors in the
clock frequency are not uncommon (that's 30 seconds a day).  Up to about
100ppm (and maybe more) you can correct by running XNTPD from the TCP
runtime, after making the above mentioned kernel patch.  On a lightly
loaded development system, with no external time source, the system has
not been out by more than 3 seconds cumulative in the last 3 months, and
the error is actually dropping as the weather gets cooler (it's in an
air conditioned room, but furthest from the air condtioning unit).  I'm
currently expecting to be within 30 seconds over the year and possibly
a lot better.
--

(Sending any email to this site constitutes a licence to copy it to any
company which might reasonably be assumed to have transported it or
might reasonably be assumed to service any addresses quoted in it. 15Sep1996)

 
 
 

SCO Real Time Clock - Yeah Right!

Post by Bela Lubki » Tue, 01 Oct 1996 04:00:00



> The hardware clock only seems to be settable to minutes (at least with
> SCO, possibly generally), so every reboot will lose, on average, half a
> minute.

It isn't a hardware limitation.  OSR5's `date` command has a "-t" flag
that lets you specify seconds (and they are faithfully carried through
to the hardware clock).
Quote:>Bela<

 
 
 

SCO Real Time Clock - Yeah Right!

Post by Roman Fietz » Thu, 03 Oct 1996 04:00:00




> > The hardware clock only seems to be settable to minutes (at least with
> > SCO, possibly generally), so every reboot will lose, on average, half a
> > minute.

> It isn't a hardware limitation.  OSR5's `date` command has a "-t" flag
> that lets you specify seconds (and they are faithfully carried through
> to the hardware clock).

And I think since OS5 the seconds are no longer lost on reboots. At
least there was a discussion about this issue and somebody mentioned
that either this is not true or that there is an easy way around that
problem.

Roman

--
Roman Fietze (Mail Code 5023)              Kodak AG Stuttgart/Germany

 
 
 

SCO Real Time Clock - Yeah Right!

Post by JüRGEN ANZ » Sat, 05 Oct 1996 04:00:00



> =


> > > The hardware clock only seems to be settable to minutes (at least wit=
h
> > > SCO, possibly generally), so every reboot will lose, on average, half=
 a
> > > minute.

> > It isn't a hardware limitation.  OSR5's `date` command has a "-t" flag
> > that lets you specify seconds (and they are faithfully carried through
> > to the hardware clock).
> =
> And I think since OS5 the seconds are no longer lost on reboots. At
> least there was a discussion about this issue and somebody mentioned
> that either this is not true or that there is an easy way around that
> problem.
> =
> Roman

Does anybody know a radio-controlled clock-card to use under SCO Unix 3.2.4=
=2E2 or OS5 ?

J=FCrgen Anzer

 
 
 

1. Mike Doughney of Domain Name Rights Coalition on ISP-TV's "Real Time"

*** ISP-TV Program Announcement:

        Michael Doughney,
        Director of Domain Name Rights Coalition
***

*** Monday, Dec. 23  ***
*** 9:00 PM ET       ***

Michael Doughney is acting director of the Domain Name Rights Coalition,
which seeks to obtain equitable, consistent and responsible domain name
policies from the National Science Foundation (NSF) and Network Solutions,
Inc. (NSI).  Doughney owns two disputed domains, "peta.org" (People Eating
Tasty Animals) which has been on hold since May, 1996, and also "mtd.com,"
which was involved in a dispute later dropped by NSI.

Doughney will talk with us about domain name disputes, what is right and
wrong with current dispute policies, and what the Domain Name Rights
Coalition hopes to achieve.

Call-in questions will be taken during the show at (301) 847-6571.

This video interview can be viewed on the ISP-TV main CU-SeeMe reflector
at IP 205.197.247.33, or other ISP-TV affiliate reflectors listed at
http://www.digex.net/isptv/members.html

See URL http://www.digex.net/isptv for more information about the ISP-TV
Network

To obtain Enhanced CU-SeeMe software, go to:

        http://goliath.wpine.com/cudownload.htm

2. background image

3. Real-Time Clock

4. AIX Certification

5. Real time clock delay problem

6. VPATH error in make

7. enhanced real time clock support; how to say 'y'

8. need experienced linux user

9. UDB and Real Time Clock

10. Real time clock (RTC) and UNIX

11. Kernel bug? Real Time Clock Freezes

12. Real time clock in shell

13. Enhanced real time clock and Alpha UP2000 SMP