I just noticed, on a pretty idle machine, this syslog output:

Sep 13 21:18:49 nelly ntpd[139]: time reset 0.390145 s
Sep 13 21:41:10 nelly ntpd[139]: time reset -0.626571 s
Sep 13 22:02:39 nelly ntpd[139]: time reset -0.647911 s
Sep 13 22:24:04 nelly ntpd[139]: time reset -0.718704 s
Sep 13 22:46:31 nelly ntpd[139]: time reset -0.629651 s
Sep 13 23:07:57 nelly ntpd[139]: time reset -0.637104 s
Sep 13 23:29:29 nelly ntpd[139]: time reset -0.651814 s
Sep 13 23:50:50 nelly ntpd[139]: time reset -0.620506 s
Sep 14 00:12:20 nelly ntpd[139]: time reset -0.621598 s

Well, obviously there must be something wrong (tm) here.

IIUC this would be caused by calling hardclock() not every 1/hz seconds,
but more often - or less, i.e. by losing clock interrupts due to blocked
higher level interrupts.

Now the machine this happens on has a sparc64 CPU, which has a %tick register.
This register is a high precision timer, running at (known) processor speed
and guaranteed to not overflow within 10 years of uptime.

So if instead of relying on hardclock() calls (which must happen regularily,
for proper scheduling) we would base timekeeping only on the %tick register,
we should get pretty accurate system clock.

Is this idea worth to be explored? Since hardclock() is MD code, it should be
fairly simple to not use it to constantly increment "time", but derive that
from a better source. I must be missing something, please enlighten me.

Martin