Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!sci.ccny.cuny.edu!jeffrey
From: jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger)
Newsgroups: comp.sys.3b1
Subject: Re: RTC precision?
Summary: Not what I was after
Keywords: RTC system clock microseconds
Message-ID: <1991Mar6.202858.17593@sci.ccny.cuny.edu>
Date: 6 Mar 91 20:28:58 GMT
References: <1991Feb27.195148.4122@sci.ccny.cuny.edu> <924@jonlab.UUCP>
Organization: City College of New York - Science Computing Facility
Lines: 36

In article <924@jonlab.UUCP> jon@jonlab.UUCP (Jon H. LaBadie) writes:
>However, there is access to a parameter that is the number of "ticks"
>since system boot.  Ticks are defined in sys/param.h as "HZ" to be 
>number of clock ticks per second.  Many things use HZ.  For example,
>the cursor is defined to be on for 2 HZ and off for 4 HZ.  Process
>accounting is logged each clock tick, not each second.
>
>On the 3B1, HZ is defined as 60 ticks per second.

Terrific, but this is a read-only sort of thing.  If I wanted to
implement a settimeofday(2) of adjtime(2) [my ultimate goal], I'd need
to control this.  But it really isn't nice to muck with the kernel's
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*
clock move either faster or slower than the hardware one.  Then, I'd
set the hardware from the software.  Assuming that this is done in one
piece of high-interrupt-level kernel code, it should be prretty
accurate.  Remember that the software clock can drop interrupts, so by
itself, the hardware clock is the real clock.  But, Thad has told me
that there is no way to use the RTC for any interval less than one
second.  Which means that the only chance I have of setting the time
more accurately then the second is by playing with the software clock
and back-feeding the hardware clock.

I'm starting to get the feeling that without beating upon the hardware
(to get better control over the clock), this issue is going to go
nowhere.  Why couldn't the designers have thought in a more general
frame of mind?  Time doesn't always move in seconds!

j
-- 
Jeffrey L. Bromberger
System Operator---City College of New York---Science Computing Facility
jeffrey@sci.ccny.cuny.edu			jeffrey@ccnysci.BITNET
	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey