[LEAPSECS] any other parties?

[Michael Spacefalcon]

Dennis Ferguson <dennis.c.ferguson at gmail.com> wrote:


> A very long time ago (more than a quarter century) BSD Unix kernels

> had code in the kernel's time-reading logic which would record the

> time returned each time the clock was read, and which would ensure

> that a subsequent call to get the time would return a time at least

> one microsecond later than that returned previously.


Your use of the past tense is incorrect: I am using one of those
OriginalBSD VAX UNIX systems right now to compose and send this post
to LEAPSECS.

My *current* 4.3BSD-Quasijarus still runs on VAX processors like the
original 4.3BSD, and the microtime() function which you are talking
about is still there in vax/machdep.c, unchanged.


> This code

> existed to cover up flaws in how the system extrapolated times between

> clock interrupts


This interpolation (not extrapolation) is only possible on large-VAX
implementations of the VAX architectured interval timer registers, on
which a register called ICR increments every microsecond (really a
rubber microsecond, as the quartz crystal oscillator is at least as
unpredictably-variable with respect to TT as Earth's rotation) and the
interval between timer interrupts can be programmed to any desired
number of these microsecond increments.  On the MicroVAX subset
implementation, which applies to the hardware I actually have and run,
the timer interrupt interval is fixed at 10 ms, and there is no way to
obtain microsecond times.

The ICR is not implemented on my MicroVAX hardware (always reads as
0), hence the microtime() code in question doesn't do anything, and
the smallest possible time resolution on my systems is 10 ms.
As I've told this list and time-nuts repeatedly, my time precision
requirements are very coarse.


> and in the implementation of adjtime(2), which otherwise

> would cause the clock to return times that did not always move forward.


There are no such flaws in the implementation of adjtime(2) taken by
itself.  Such aberrations are possible only when one combines the
adjtime mechanism with the microsecond ICR hack, and indeed the
forward-only enforcement hack fixes the problem.

However, the issue isn't relevant to my current systems which lack the
microsecond time mechanism altogether, and I personally question the
wisdom of whoever has implemented that microtime() hack in the first
place: in my mind there is absolutely no problem with simply reckoning
time in 10 ms increments as MicroVAXen do.  There is absolutely no
need for finer civil time resolution in a general-purpose computer/OS.


> settimeofday(2) had

> the side effect of resetting the internal variable holding the last time

> returned,


Wrong: that variable is declared as static inside the microtime()
function, hence the settimeofday(2) code path has no access to it.

SF