by Hi,
Is usec_per_tick under Solaris 2.4/x86 a placebo? The issue has got
me baffled, and any input would be greatly appreciated.
The background: I'm attempting to run xntp on Solaris 2.4/x86,
but the clock shows a drift greater than the 300ppm or so that
xntp is capable of correcting, so it seems time for a kernel tweak.
After reading manuals and getting input from comp.protocols.time.ntp
(thanks, Bruce!) I believe time management in Solaris 2.4/x86 works
as follows:
-- there are two clocks in the kernel. One counts the nano-
seconds since system boottime (for the benefit of gethrtime(2)),
the other the seconds and microseconds since jan 1st, 1970
(for the benefit of gettimeofday(2)).
-- The microsecond counter is subject to leap-seconds and
adjustments using adjtime(2) in order to keep it synchronised
with time in the rest of the world. The nanosecond counter
is for performance measurements, and is not subject to such
adjustments.
-- A programmable interrupt timer is set to go off at a rate of
100 Hz. On every interrupt, the operating system clocks are
incremented by usec_per_tick and nsec_per_tick, respectively.
-- If the variable dosynctodr is set, the OS will keep the micro-
second timer in sync with the built-in real-time clock.
So in order to get my clock run a bit faster, I switched off dosynctodr,
increased usec_per_tick to 15000 and increased nsec_per_tick to 15000000.
This was done in /etc/system, and correct settings were verified with
adb -k /kernel/unix. This should have the effect of speeding up the
clock to 40 seconds per minute of wallclock time, but in fact there was
absolutely no change in clock behaviour.
Does anyone have an explanation? Do I need to set yet another kernel
variable, to apply some patch, or is there simply no way to adjust the
clock speed on Solaris other than through adjtime(2)?
Thanks,
Erik