Newsgroups: comp.sys.sun.apps,comp.sys.hp,comp.parallel.pvm,comp.sys.dec
Path: ukc!uknet!pipex!howland.reston.ans.net!paladin.american.edu!constellation!rex!ben
From: ben@rex.uokhsc.edu (Benjamin Z. Goldsteen)
Subject: Re: Accessing Real Time Clock in workstations (HPs, Suns, Dec Alphas)
Message-ID: <CK595E.FHw@rex.uokhsc.edu>
Date: Mon, 24 Jan 1994 17:12:50 GMT
Reply-To: benjamin-goldsteen@uokhsc.edu
References: <2hmq76INNd2e@flop.ENGR.ORST.EDU> <CJy6yC.B1K@cup.hp.com>
Organization: Health Sciences Center, University of Oklahoma
Lines: 80
Xref: ukc comp.sys.sun.apps:6118 comp.sys.hp:39057 comp.parallel.pvm:1240 comp.sys.dec:18467

pdg@cup.hp.com (Paul Gootherts) writes:

>NeoSwami (padalam@research.CS.ORST.EDU) wrote:
>>   We are looking for a similar kind of routine for the following workstations:
>>   ...
>>   HP 700 series [715/730]
>>   ...

>Take a look at gettimeofday(2).

>Paul Gootherts
>pdg@cup.hp.com

     I think a number of people have said this but am guessing that
there is not enough resolution in it.  I don't remember what type of
instrumentation he said he was doing but the time to do a typical
system call will overwhelm what one can get from a real-time clock. 
The IBM RS/6000 clock he was referring to is accessible by a few
assembly language instructions and offers microsecond precision:

> Newsgroups: comp.unix.aix
> Path: rex!constellation!convex!convex!cs.utexas.edu!uunet!newsgate.watson.ibm.com!yktnews.watson.ibm.com!yktnews!prener
> From: prener@watson.ibm.com (Dan Prener)
> Subject: Re: Memory mapped clock
> Sender: news@yktnews.watson.ibm.com (NNTP News Poster)
> Message-ID: <PRENER.93May31015847@prener.watson.ibm.com>
> In-Reply-To: gerth@watson.ibm.com's message of Fri, 28 May 1993 14:14:44 GMT
> Date: Mon, 31 May 1993 06:58:47 GMT
> Disclaimer: This posting represents the poster's views, not necessarily those of IBM.
> References: <0E062001.2iihl1@anubis.han.de> <C7qq8K.rws@hawnews.watson.ibm.com>
> Nntp-Posting-Host: prener.watson.ibm.com
> Organization: IBM T.J. Watson Research Center, Hawthorne, New York
> Lines: 39
> 
> In article <C7qq8K.rws@hawnews.watson.ibm.com> gerth@watson.ibm.com (John Gerth) writes:
> 
>   [ ... ]
> 
> > The real-time clock on the S/6000 is readable from a user-level program.
> > You need to actually do the reading in an assembler routine (there are
> > a couple of good publications which show this in detail - GG24-3633 AIX
> > Version 3 as a Real-Time System" and GG24-3711 "Predicting Execution Time
> > on the IBM Risc System/6000").  The clock consists of two 32-bit integer
> > words - one with seconds, the other with nanonseconds, i.e. if you combine
> > the two you can get a double with resolution much finer than the "clock tick".
> 
> > Here's the meat of the assembler (I'm not providing any housekeeping):
> >   .rtc_upper:
> > 	.globl	.rtc_upper
> > 	mfspr	3,4
> > 	br
> >   .rtc_lower:
> > 	.globl	.rtc_lower
> > 	mfspr	3,5
> > 	br 
> > These would be used as follows:
> >  double time_in_seconds(){
> > 	double tl,tu;
> > 	tu = rtc_upper();
> > 	tl = rtc_lower();
> > 	return (tu + (tl/1000000000));
> >  }
> 
> A more robust approach is to read the upper half of the clock, then read the
> lower half, then read the upper half again.  If the two reads of the upper
> half are different, discard the whole thing and start over, since you cannot
> be sure that the lower-half reading corresponds to a given one of the
> upper-half readings.
> 
> According to your taste, this entire process could be incorporated in
> a single assembler routine, or wrapped around the two routines above.
> --
>                                    Dan Prener (prener@watson.ibm.com)

P.S.Not picking on you, but I have yet to see the right answer and I
don't really believe no other UNIX offers better than millisecond
resolution.  My apologies if HP's gettimeofday(2) is considerably
faster and more precise than other UNIX's...
-- 
Benjamin Z. Goldsteen

