Re: Timing Ada programs using the DEC UNIX microtimer kernel option

[jonathan@Kowhai.Stanford.EDU (Jonathan Stone)]

In article <gwinn-2504981807010001@d45.dial-4.cmb.ma.ultra.net>, 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.