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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1164f8,b3c24209310418d0 X-Google-Attributes: gid1164f8,public X-Google-Thread: 103376,b3c24209310418d0 X-Google-Attributes: gid103376,public X-Google-Thread: fee84,b3c24209310418d0 X-Google-Attributes: gidfee84,public From: jonathan@Kowhai.Stanford.EDU (Jonathan Stone) Subject: Re: Timing Ada programs using the DEC UNIX microtimer kernel option Date: 1998/04/26 Message-ID: <6hu3hr$8v4$1@nntp.Stanford.EDU>#1/1 X-Deja-AN: 347705405 References: <6hsab5$rh1$1@eplet.mira.net.au> Reply-To: jonathan@DSG.Stanford.EDU Organization: Stanford Distributed Systems Grop Newsgroups: comp.unix.osf.osf1,comp.sys.dec,comp.lang.ada Date: 1998-04-26T00:00:00+00:00 List-Id: In article , gwinn@ma.ultranet.com (Joe Gwinn) writes: [snip] |> A POSIX.1b time structure contains two 32-bit unsigned integer fields, the |> first field being seconds since 00:00:00 UTC 1 January 1970 AD (UNIX |> timescale origin), and the second field being decimal nanoseconds into the |> current second. Many UNIX systems have much the same setup, except that |> the nanoseconds longword instead contains microseconds into the current |> second. |> |> The monotonic-clock implementation used by DEC and others is that every |> time the 1024-Hz tick arrives, the microsecond count is incremented by |> 1,024 mic024-Hz tick arrives, the microsecond count is incremented by |> 1,024 microseconds, or the nanosecond count is incremented by 1,024,000 |> nanoseconds. Just a nitpick, but it's actually 976 usecs, or about 976563 nanoseconds. When using microsecond resolution (as here), handling the the remaining 576 usecs gracefully requires some care. In increasing sophistication: * have a `fat tick' once per second which acculates all 576 usecs. That's what the Historic BSD code did. Here, that's more than 50% bigger than normal ticks, which is really nasty for accurate time-keeping. * Compute the gcd and spread the remainder over more ticks--here, compute G=gcd(1024, 576), and bump the clock by 576/G every 1024/G ticks. * Extended-precision arithmetic. Keep a counter of fractional ticks (here, 576/hz), and bump the usec ( or nsec) count by one when you've accumulated a whole usec's worth of fractional ticks. The NTP kernel clock model uses about six bits of binary fractions of a microsecond. (Line-plotting algorithms arent used here because they often round up, which breaks monotonicity and is disastrous for timekeeping.) |> In addition, whenever the clock is read, the lsb of the |> microsecond (or nanosecond) longword is incremented using an |> atomic-increment machine instruction. So, timestamps are a combination of |> a time and a serial number. The note from DEC didn't say if the serial |> number portion is ever zeroed, but I would guess that it is zeroed on |> every clock tick. The typical implementation bumps tv_usec on each read, and maintains `usecs at last tick' indepenently, and resets tv_usec to that value at each clock interrupt. |> Another approach (not used by DEC for the systems mentioned) is to have |> actual microsecond clock hardware. 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.