Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!voder!pyramid!ctnews!mitisft!dold
From: dold@mitisft.Convergent.COM (Clarence Dold)
Newsgroups: comp.sys.3b1
Subject: Re: RTC precision?
Message-ID: <1906@mitisft.Convergent.COM>
Date: 8 Mar 91 19:20:47 GMT
References: <1991Mar6.202858.17593@sci.ccny.cuny.edu>
Organization: Convergent Technologies, San Jose, CA
Lines: 32

in article <1991Mar6.202858.17593@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) says:

> tick counter.  What I'm really after is some way to adjust the 3b1's
> clock to something smaller than a second.  Somehow, the LOSE/TCP code
> sends stuff out with useconds.  All I'm after is a way to make a *software*

The tv_usec returned by gettimeofday() is either 0, or time() % 60 * 10000
neither of them is really usec, it just looks good.

> itself, the hardware clock is the real clock.  

arguably true, but not very often...

The RTC chip is like a wristwatch (except terribly inaccurate).  The system
time (software clock) looks at it's wristwatch when it wakes up in the 
morning (boot time script), and possibly from time to time throughout
the day (via cron scripts).  I stretched that analogy far enough :-)

As far as my rapidly fading memory can recall, unless you do a "date -", 
the system clock is never adjusted to match the RTC.  When you specify a 
new date with "date 0306123491", you set the system time, and drive that
into the RTC.

In fact, an stime() call by itself doesn't set the RTC, just the system.
You must use syslocal(SYSL_WTRTC) to change the RTC, which 'date' does.
SYSL_WTRTC is the name on later Convergent boxes, I forget what it is on
the 3b1, but it's close.

-- 
---
Clarence A Dold - dold@tsmiti.Convergent.COM
               ...pyramid!ctnews!tsmiti!dold