From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fee84,b3c24209310418d0
X-Google-Attributes: gidfee84,public
X-Google-Thread: 1164f8,b3c24209310418d0
X-Google-Attributes: gid1164f8,public
X-Google-Thread: 103376,b3c24209310418d0
X-Google-Attributes: gid103376,public
From: mogul@actitis.pa.dec.com (Jeffrey Mogul)
Subject: Re: Timing Ada programs using the DEC UNIX microtimer kernel option
Date: 1998/04/28
Message-ID: <6i37j6$ch7@usenet.pa.dec.com>#1/1
X-Deja-AN: 348256892
References: <6hsab5$rh1$1@eplet.mira.net.au>
 <gwinn-2504981807010001@d45.dial-4.cmb.ma.ultra.net>
 <6hu3hr$8v4$1@nntp.Stanford.EDU>
Organization: DEC Western Research
Newsgroups: comp.unix.osf.osf1,comp.sys.dec,comp.lang.ada
Date: 1998-04-28T00:00:00+00:00
List-Id: <comp.lang.ada>



In article <6hu3hr$8v4$1@nntp.Stanford.EDU>, jonathan@Kowhai.Stanford.EDU (Jonathan Stone) writes:
|> 
|> But all Alphas have a high-resolution CPU cycle-counter, or an I/O bus
|> cycle-counter to get usec or better resolution.  As well as that,
|> there's usually either a PC-compatible timer chip or a cycle-counter
|> on the I/O bus.  If you find the CPu clock speed (e.g., via busy-loop
|> counting cycles between clockticks early in boot) it's easy to
|> interpolate from any of these to usec or 10s of nanosec resolution.
|> 
|> For uniprocessors (like the machines here), you can use CPU cycles
|> directly.  Multiprocessors require more care to keep the per-CPU
|> cycle-counter value at each realtime clock tick, or the process' clock
|> values jump around when context-switching from one CPU to another.  Or
|> you can just use a lower-resolution, but shared, IO bus cycle counter.
|> 
|> I seem to recall Dave Mills saying that DEC gave him some hardware
|> precisely to get NTP and precision timekeeping correct.
|> It would be rather odd if DU still doesnt get this right.

In fact, the MICRO_TIME option (in Digital UNIX V4.0 and later)
is exactly this code.  Thanks to Dave Mills, if this option is
enabled, the kernel uses the cycle counter to interpolate between
clock interrupts, and the result is provided by gettimeofday().

Dave also managed to get this to work on multiprocessors, in the
sense that if a process migrates from one CPU to another, it should
still see consistent and accurate time from gettimeofday().  There
may be some bugs in earlier versions of this code (I've heard rumors
of 12-CPU systems where it didn't quite work), so if you do have
a large SMP system and want to enable this option, you might want to
get the latest release of the operating system and proceed with some
prudent care.

See the Digital UNIX FAQ:
  ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/Digital-UNIX
under "P9. How can I get microsecond resolution from gettimeofday(2)?"
for more details.

-Jeff