The audit trail to pr/24207 has the start of a discussion that IMHO should
be better here.

The problem, as Jason explained in that PR: microtime(9) traditionally
promissed to never return the same values on successive calls, no matter
what CPU the call runs on.

This implies global (not only per CPU) state and aproppriate locking.

Ntpd does not like this locking, but we can not keep the monotonic non
repeating API promise without it.

We could, however, easily implement a very accurate mircotime_ng(9) [or
whatever you'd like to call it] that does not do the locking, does not
promise to deliver different values on successive calls, and still
provides a very exact estimate of the time. If a process happens to
switch CPUs between two calls it might even make time go slightly
backward. We sync time between CPUs once every second, and cycle counter
equipped CPUs should be able to provide consistent results in between,
so for "normal" usage IMHO this variant of microtime should be enough.

We could then, in a second step, sweep through the kernel and identify
calls to microtime() that depend on the strong monotonic behaviour, and
replace all others with calls to the new function.

What do you think?

Martin