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