>Is not the problem really still there, but not showing up as often
>after 'tick' is tweaked like this?
>Running the 'tickadj' program tells me that xntpd wants the corresponding
>kernel variable set at 5 us, and that there are no such variable in the
>(Solaris 2.x) kernel. The syslog from xntpd says the variable is set
>to 625 us, which is much to large for xntpd to work well.
>If Solaris 2.x really use a tickadj value of 625 us (and if that
>can not be changed), xntpd really should know about the nsec_per_tick
>kernel variable and use that one to slew the clock instead of
>calling adjtime. Comments?
In BSD systems 'tick' controls the number of microseconds for each
hardware clock tick, and 'tickadj' is the rounding factor that all
calls to adjtime() are silently rounded to. xntp wants to know about
tickadj to compensate for this rounding, and it wants the rounding
factor to be as small as possible (thus wanting tickadj to be 5
Solaris 2.x (x >= 2) does not round its adjtime() calls at all. In
the xntp code this is what ADJTIME_IS_ACCURATE means. When you call
adjtime(), Solaris applies 1/16 of the clock tick as correction on
each tick until the last, when it applies the exact remaining amount.
For example if the clock tick is 10 msec, and you call adjtime to
slew the clock by 2 msec, on the next clock tick Solaris will adjust
the clock by 10/16 = 1.6 msec, and the clock tick after it will apply
exactly .4 msec.
Other parts of xntp want to make calculations based on the value of
'tickadj', so I fudged and said tickadj = tick/16, or 625 usec. But
since ADJTIME_IS_ACCURATE is defined xntpd does not use the value of
tickadj to determine the rounding, it knows there is no rounding. In
other words you should ignore tickadj claiming 625 usec and wanting 5
usec, it is meaningless on Solaris (and Irix, and any other system
The change is /etc/system to set nsec_per_tick is reasonable.
>On the machines with Solaris 2.4 running xntpd 3.4o I am running,
>xntpd is mostly able to keep the syncronisation in the 1-2 ms range
>but occasionally (minutes to hours between) the offset jumps to 10-50 ms.
>This I don't think can be made much better with the nsec_per_tick hack.
>One machine with Solaris 2.3 (and earlier 2.2) have severe problems and
>drops out of the (128ms?) window regularly. I suppose this machine could
>be made to work as well as the 2.4's with the nsec_per_tick hack.
Are these by chance multiprocessor machines? If so, install the most
recent kernel patch. There was a bug found in dealing with clock
ticks on MP machines, it was possible for the clock interrupt to get
taken twice which would jump the time ahead by 10 msec.
Also make absolutely sure that dosynctodr is set to 0 in /etc/system.