3 <TITLE>Solaris hints and kinks</title><link href="scripts/style.css" type="text/css" rel="stylesheet">
7 Information on compiling and executing ntpd under Solaris.
10 <!-- #BeginDate format:En2m -->27-Jan-2014 05:31<!-- #EndDate -->
13 <! -- This is deliberately not a mailto -- > <jhawk@MIT.EDU>
16 If you're not running Solaris 2.5.1 or later, it is likely
17 that you will have problems; upgrading would be a really good plan.
19 <H3>All Solaris versions</H3>
21 We have a report that says starting with Solaris 2.6 we should leave
22 <I>dosynctodr</I> alone.
23 <A HREF="solaris-dosynctodr.html">Here is the report</A>.
25 Proper operation of ntp under Solaris may require setting the kernel
26 variable <I>dosynctodr</I> to zero (meaning "do not synchronize the clock
27 to the hardware time-of-day clock"). This can be done with the
32 If you prefer, it can also be done with the native Solaris kernel debugger:
34 echo dosynctodr/W0 | adb -k -w /dev/ksyms /dev/mem
37 Or, it can also be set by adding a line to /etc/system:
42 Instead of the <I>tick</I> kernel variable, which many operating
43 systems use to control microseconds added to the system time every
44 clock tick (c.f. <A HREF="#frequency_tolerance">Dealing
45 with Frequency Tolerance Violations</A>), Solaris has the variables
46 <I>nsec_per_tick</I> and <I>usec_per_tick</I>.
48 <I>nsec_per_tick</I> and <I>usec_per_tick</I> control the number of
49 nanoseconds and microseconds, respectively, added to the system clock
50 each clock interrupt. Enterprising souls may set these based on
51 information collected by ntpd in the <CODE>/etc/ntp.drift</CODE> file
52 to correct for individual hardware variations.
54 On UltraSPARC systems, <I>nsec_per_tick</I> and <I>usec_per_tick</I>
55 are ignored in favor of the <I>cpu_tick_freq</I> variable, which
56 should be automatically be determined by the PROM in an accurate
59 In general, the same ntp binaries should not be used across multiple
60 operating system releases. There is enough variation in the core operating
61 system support for timekeeping that a rebuild of ntpd for the idiosyncracies
62 of your specific operating system version is advisable.
64 It is recommended that ntp be started via a script like <A
65 HREF="solaris.xtra.S99ntpd">this one</A>, installed in
66 <CODE>/etc/init.d/ntpd</CODE> with a symbol link from
67 <CODE>/etc/rc2.d/S99ntpd</CODE>.
69 <a id="frequency_tolerance" />
70 <h4>Dealing with Frequency Tolerance Violations (<tt>tickadj</tt> and
72 The NTP Version 3 specification RFC-1305 calls for a maximum
73 oscillator frequency tolerance of +-100 parts-per-million (PPM), which is
74 representative of those components suitable for use in relatively
75 inexpensive workstation platforms. For those platforms meeting this
76 tolerance, NTP will automatically compensate for the frequency errors of the
77 individual oscillator and no further adjustments are required, either to the
78 configuration file or to various kernel variables. For the NTP Version 4
79 release, this tolerance has been increased to +-500 PPM. <p>However, in the
80 case of certain notorious platforms, in particular Sun 4.1.1 systems, the
81 performance can be improved by adjusting the values of certain kernel
82 variables; in particular, <tt>tick</tt> and <tt>tickadj</tt>. The variable
83 <tt>tick</tt> is the increment in microseconds added to the system time on
84 each interval- timer interrupt, while the variable <tt>tickadj</tt> is used
85 by the time adjustment code as a slew rate, in microseconds per tick. When
86 the time is being adjusted via a call to the system routine
87 <tt>adjtime()</tt>, the kernel increases or reduces tick by <tt>tickadj</tt>
88 microseconds per tick until the specified adjustment has been
89 completed. Unfortunately, in most Unix implementations the tick increment
90 must be either zero or plus/minus exactly <tt>tickadj</tt> microseconds,
91 meaning that adjustments are truncated to be an integral multiple of
92 <tt>tickadj</tt> (this latter behaviour is a misfeature, and is the only
93 reason the <tt>tickadj</tt> code needs to concern itself with the internal
94 implementation of <tt>tickadj</tt> at all). In addition, the stock Unix
95 implementation considers it an error to request another adjustment before a
96 prior one has completed.</p> <p>Thus, to make very sure it avoids problems
97 related to the roundoff, the <tt>tickadj</tt> program can be used to adjust
98 the values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all
99 adjustments given to <tt>adjtime()</tt> are an even multiple of
100 <tt>tickadj</tt> microseconds and computes the largest adjustment that can
101 be completed in the adjustment interval (using both the value of
102 <tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding
103 this limit. It is important to note that not all systems will allow
104 inspection or modification of kernel variables other than at system build
105 time. It is also important to know that, with the current NTP tolerances, it
106 is rarely necessary to make these changes, but in many cases they will
107 substantially improve the general accuracy of the time service.</p>
108 <p>Unfortunately, the value of <tt>tickadj</tt> set by default is almost
109 always too large for <tt>ntpd</tt>. NTP operates by continuously making
110 small adjustments to the clock, usually at one-second intervals. If
111 <tt>tickaj</tt> is set too large, the adjustments will disappear in the
112 roundoff; while, if <tt>tickadj</tt> is too small, NTP will have difficulty
113 if it needs to make an occasional large adjustment. While the daemon itself
114 will read the kernel's values of these variables, it will not change the
115 values, even if they are unsuitable. You must do this yourself before the
116 daemon is started using the <tt>tickadj</tt> program included in the
117 <tt>./util</tt> directory of the distribution. Note that the latter program
118 will also compute an optimal value of <tt>tickadj</tt> for NTP use based on
119 the kernel's value of <tt>tick</tt>.</p> <p>The <tt>tickadj</tt> program can
120 reset several other kernel variables if asked. It can change the value of
121 <tt>tick</tt> if asked. This is handy to compensate for kernel bugs which
122 cause the clock to run with a very large frequency error, as with SunOS
123 4.1.1 systems. It can also be used to set the value of the kernel
124 <tt>dosynctodr</tt> variable to zero. This variable controls whether to
125 synchronize the system clock to the time-of-day clock, something you really
126 don't want to be happen when <tt>ntpd</tt> is trying to keep it under
127 control. In some systems, such as recent Sun Solaris kernels, the
128 <tt>dosynctodr</tt > variable is the only one that can be changed by the
129 <tt>tickadj</tt> program. In this and other modern kernels, it is not
130 necessary to change the other variables in any case.</p>
132 <p>We have a report that says starting with Solaris 2.6 we should leave
133 <i>dosynctodr</i> alone.</p> <p>In order to maintain reasonable correctness
134 bounds, as well as reasonably good accuracy with acceptable polling
135 intervals, <tt>ntpd</tt> will complain if the frequency error is greater
136 than 500 PPM. For machines with a value of <tt>tick</tt> in the 10-ms range,
137 a change of one in the value of <tt>tick</tt> will change the frequency by
138 about 100 PPM. In order to determine the value of <tt>tick</tt> for a
139 particular CPU, disconnect the machine from all source s of time
140 (<tt>dosynctodr</tt> = 0) and record its actual time compared to an outside
141 source (eyeball-and-wristwatch will do) over a day or more. Multiply the
142 time change over the day by 0.116 and add or subtract the result to tick,
143 depending on whether the CPU is fast or slow. An example call to
144 <tt>tickadj</tt> useful on SunOS 4.1.1 is:</p>
146 <tt>tickadj</tt> -t 9999 -a 5 -s
148 which sets tick 100 PPM fast, <tt>tickadj</tt> to 5 microseconds and turns
149 off the clock/calendar chip fiddle. This line can be added to the <tt
150 >rc.local</tt> configuration file to automatically set the kernel variables
151 at boot time. <p>All this stuff about diddling kernel variables so the NTP
152 daemon will work is really silly. If vendors would ship machines with clocks
153 that kept reasonable time and would make their <tt>adjtime()</tt> system
154 call apply the slew it is given exactly, independent of the value of
155 <tt>tickadj</tt>, all this could go away. This is in fact the case on many
156 current Unix systems.</p>
160 Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this
161 support in such a fashion that using it worse than not. This is <A
162 HREF="solaris.xtra.4095849"> SUN Bug ID 4095849</A>, and it is not yet
163 fixed as of June 1998.
165 <H3>Solaris 2.5 and 2.5.1</H3>
167 On UltraSPARC systems, calculation of <I>cpu_tick_freq</I> is broken
168 such that values that are off by significant amounts may be used
169 instead. This unfortunately means that ntpd may have severe problems
170 keeping synchronization. This is <A HREF="solaris.xtra.4023118"> SUN Bug ID
171 4023118</A>. Bryan Cantrill <! -- <bmc@eng.sun.com> --> of Sun
172 posted <A HREF="solaris.xtra.patchfreq">patchfreq</A>, a workaround script,
173 to comp.protocols.time.ntp in March of 1997.
177 <STRONG>I can't vouch for the accuracy the information below this
178 rule. It may be significantly dated or incorrect.</STRONG>
183 Solaris 2.2 and later contain completely re-written clock code to
184 provide high resolution microsecond timers. A benefit of the
185 re-written clock code is that adjtime does not round off its
186 adjustments, so ntp does not have to compensate for this
187 rounding. Under Solaris 2.2 and later, ntp #define's
188 <CODE>ADJTIME_IS_ACCURATE</CODE>, and does not look for the <I>tickadj</I>
192 (This originally written by William L. Jones <jones@chpc.utexas.edu>)
194 Solaris 2.1 contains fairly traditional clock code, with <I>tick</I>
197 Since settimeofday under Solaris 2.1 only sets the seconds part of timeval
198 care must be used in starting xntpd. I suggest the following start
202 <BR>ntpdate -v server1 server2
204 <BR>ntpdate -v server1 server2
210 The first tickadj turns of the time of day clock and sets the tick
211 adjust value to 1 millisecond. This will insure that an adjtime value
212 of at most 2 seconds will complete in 20 seconds.
214 The first ntpdate will set the time to within two seconds
215 using settimeofday or it will adjust time using adjtime.
217 The first sleep insures the adjtime has completed for the first ntpdate.
219 The second ntpdate will use adjtime to set the time of day since the
220 clock should be within 2 seconds of the correct time.
222 The second tickadj set the tick adjust system value to 5 microseconds.
224 The second sleeps insure that adjtime will complete before starting
227 I tried running with a tickadj of 5 microseconds with out much success.
228 200 microseconds seems to work well.
231 Prior versions of this file had major text contributed by:
233 <LI>Denny Gentry <denny@eng.sun.com>
projects / FreeBSD / releng / 10.2.git / blob