If you're not running Solaris 2.5.1 or later, it is likely that you will have problems; upgrading would be a really good plan.
We have a report that says starting with Solaris 2.6 we should leave dosynctodr alone. Here is the report.
Proper operation of ntp under Solaris may require setting the kernel variable dosynctodr to zero (meaning "do not synchronize the clock to the hardware time-of-day clock"). This can be done with the tickadj utility:
tickadj -sIf you prefer, it can also be done with the native Solaris kernel debugger:
echo dosynctodr/W0 | adb -k -w /dev/ksyms /dev/mem
Or, it can also be set by adding a line to /etc/system:
set dosynctodr = 0
Instead of the tick kernel variable, which many operating systems use to control microseconds added to the system time every clock tick (c.f. Dealing with Frequency Tolerance Violations), Solaris has the variables nsec_per_tick and usec_per_tick.
nsec_per_tick and usec_per_tick control the number of
nanoseconds and microseconds, respectively, added to the system clock
each clock interrupt. Enterprising souls may set these based on
information collected by ntpd in the /etc/ntp.drift file
to correct for individual hardware variations.
On UltraSPARC systems, nsec_per_tick and usec_per_tick are ignored in favor of the cpu_tick_freq variable, which should be automatically be determined by the PROM in an accurate fashion.
In general, the same ntp binaries should not be used across multiple operating system releases. There is enough variation in the core operating system support for timekeeping that a rebuild of ntpd for the idiosyncracies of your specific operating system version is advisable.
It is recommended that ntp be started via a script like this one, installed in
/etc/init.d/ntpd with a symbol link from
/etc/rc2.d/S99ntpd.
Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this support in such a fashion that using it worse than not. This is SUN Bug ID 4095849, and it is not yet fixed as of June 1998.
On UltraSPARC systems, calculation of cpu_tick_freq is broken such that values that are off by significant amounts may be used instead. This unfortunately means that ntpd may have severe problems keeping synchronization. This is SUN Bug ID 4023118. Bryan Cantrill of Sun posted patchfreq, a workaround script, to comp.protocols.time.ntp in March of 1997.
Solaris 2.2 and later contain completely re-written clock code to
provide high resolution microsecond timers. A benefit of the
re-written clock code is that adjtime does not round off its
adjustments, so ntp does not have to compensate for this
rounding. Under Solaris 2.2 and later, ntp #define's
ADJTIME_IS_ACCURATE, and does not look for the tickadj
kernel variable.
Solaris 2.1 contains fairly traditional clock code, with tick and tickadj.
Since settimeofday under Solaris 2.1 only sets the seconds part of timeval care must be used in starting xntpd. I suggest the following start up script:
tickadj -s -a 1000The first tickadj turns of the time of day clock and sets the tick adjust value to 1 millisecond. This will insure that an adjtime value of at most 2 seconds will complete in 20 seconds.
ntpdate -v server1 server2
sleep 20
ntpdate -v server1 server2
sleep 20
tickadj -a 200
xntpd
The first ntpdate will set the time to within two seconds using settimeofday or it will adjust time using adjtime.
The first sleep insures the adjtime has completed for the first ntpdate.
The second ntpdate will use adjtime to set the time of day since the clock should be within 2 seconds of the correct time.
The second tickadj set the tick adjust system value to 5 microseconds.
The second sleeps insure that adjtime will complete before starting the next xntpd.
I tried running with a tickadj of 5 microseconds with out much success. 200 microseconds seems to work well.