1258945Sroberto<HTML> 2258945Sroberto<HEAD> 3258945Sroberto<TITLE>Solaris hints and kinks</title><link href="scripts/style.css" type="text/css" rel="stylesheet"> 4258945Sroberto 5258945Sroberto</HEAD> 6258945Sroberto<BODY> 7258945SrobertoInformation on compiling and executing ntpd under Solaris. 8258945Sroberto<BR> 9275970Scy<p>Last update: 10275970Scy <!-- #BeginDate format:En2m -->27-Jan-2014 05:31<!-- #EndDate --> 11275970Scy UTC, 12258945SrobertoJohn Hawkinson, 13258945Sroberto<! -- This is deliberately not a mailto -- > <jhawk@MIT.EDU> 14275970Scy</p> 15258945Sroberto<P> 16258945SrobertoIf you're not running Solaris 2.5.1 or later, it is likely 17258945Srobertothat you will have problems; upgrading would be a really good plan. 18258945Sroberto<P> 19258945Sroberto<H3>All Solaris versions</H3> 20258945Sroberto<P> 21258945Sroberto We have a report that says starting with Solaris 2.6 we should leave 22258945Sroberto <I>dosynctodr</I> alone. 23258945Sroberto <A HREF="solaris-dosynctodr.html">Here is the report</A>. 24258945Sroberto<P> 25258945SrobertoProper operation of ntp under Solaris may require setting the kernel 26258945Srobertovariable <I>dosynctodr</I> to zero (meaning "do not synchronize the clock 27258945Srobertoto the hardware time-of-day clock"). This can be done with the 28258945Srobertotickadj utility: 29258945Sroberto<BLOCKQUOTE><TT> 30258945Srobertotickadj -s 31258945Sroberto</TT></BLOCKQUOTE> 32258945SrobertoIf you prefer, it can also be done with the native Solaris kernel debugger: 33258945Sroberto<BLOCKQUOTE><TT> 34258945Srobertoecho dosynctodr/W0 | adb -k -w /dev/ksyms /dev/mem 35258945Sroberto</BLOCKQUOTE></TT> 36258945Sroberto<P> 37258945SrobertoOr, it can also be set by adding a line to /etc/system: 38258945Sroberto<BLOCKQUOTE><TT> 39258945Srobertoset dosynctodr = 0 40258945Sroberto</BLOCKQUOTE></TT> 41258945Sroberto<P> 42258945SrobertoInstead of the <I>tick</I> kernel variable, which many operating 43258945Srobertosystems use to control microseconds added to the system time every 44275970Scyclock tick (c.f. <A HREF="#frequency_tolerance">Dealing 45258945Srobertowith Frequency Tolerance Violations</A>), Solaris has the variables 46258945Sroberto<I>nsec_per_tick</I> and <I>usec_per_tick</I>. 47258945Sroberto<P> 48258945Sroberto<I>nsec_per_tick</I> and <I>usec_per_tick</I> control the number of 49258945Srobertonanoseconds and microseconds, respectively, added to the system clock 50258945Srobertoeach clock interrupt. Enterprising souls may set these based on 51258945Srobertoinformation collected by ntpd in the <CODE>/etc/ntp.drift</CODE> file 52258945Srobertoto correct for individual hardware variations. 53258945Sroberto<P> 54258945SrobertoOn UltraSPARC systems, <I>nsec_per_tick</I> and <I>usec_per_tick</I> 55258945Srobertoare ignored in favor of the <I>cpu_tick_freq</I> variable, which 56258945Srobertoshould be automatically be determined by the PROM in an accurate 57258945Srobertofashion. 58258945Sroberto<P> 59258945SrobertoIn general, the same ntp binaries should not be used across multiple 60258945Srobertooperating system releases. There is enough variation in the core operating 61258945Srobertosystem support for timekeeping that a rebuild of ntpd for the idiosyncracies 62258945Srobertoof your specific operating system version is advisable. 63258945Sroberto<P> 64258945SrobertoIt is recommended that ntp be started via a script like <A 65258945SrobertoHREF="solaris.xtra.S99ntpd">this one</A>, installed in 66258945Sroberto<CODE>/etc/init.d/ntpd</CODE> with a symbol link from 67258945Sroberto<CODE>/etc/rc2.d/S99ntpd</CODE>. 68258945Sroberto 69275970Scy<a id="frequency_tolerance" /> 70275970Scy<h4>Dealing with Frequency Tolerance Violations (<tt>tickadj</tt> and 71275970ScyFriends)</h4> 72275970Scy The NTP Version 3 specification RFC-1305 calls for a maximum 73275970Scy oscillator frequency tolerance of +-100 parts-per-million (PPM), which is 74275970Scyrepresentative of those components suitable for use in relatively 75275970Scyinexpensive workstation platforms. For those platforms meeting this 76275970Scytolerance, NTP will automatically compensate for the frequency errors of the 77275970Scyindividual oscillator and no further adjustments are required, either to the 78275970Scyconfiguration file or to various kernel variables. For the NTP Version 4 79275970Scyrelease, this tolerance has been increased to +-500 PPM. <p>However, in the 80275970Scycase of certain notorious platforms, in particular Sun 4.1.1 systems, the 81275970Scyperformance can be improved by adjusting the values of certain kernel 82275970Scyvariables; in particular, <tt>tick</tt> and <tt>tickadj</tt>. The variable 83275970Scy<tt>tick</tt> is the increment in microseconds added to the system time on 84275970Scyeach interval- timer interrupt, while the variable <tt>tickadj</tt> is used 85275970Scyby the time adjustment code as a slew rate, in microseconds per tick. When 86275970Scythe time is being adjusted via a call to the system routine 87275970Scy<tt>adjtime()</tt>, the kernel increases or reduces tick by <tt>tickadj</tt> 88275970Scymicroseconds per tick until the specified adjustment has been 89275970Scycompleted. Unfortunately, in most Unix implementations the tick increment 90275970Scymust be either zero or plus/minus exactly <tt>tickadj</tt> microseconds, 91275970Scymeaning that adjustments are truncated to be an integral multiple of 92275970Scy<tt>tickadj</tt> (this latter behaviour is a misfeature, and is the only 93275970Scyreason the <tt>tickadj</tt> code needs to concern itself with the internal 94275970Scyimplementation of <tt>tickadj</tt> at all). In addition, the stock Unix 95275970Scyimplementation considers it an error to request another adjustment before a 96275970Scyprior one has completed.</p> <p>Thus, to make very sure it avoids problems 97275970Scyrelated to the roundoff, the <tt>tickadj</tt> program can be used to adjust 98275970Scythe values of <tt>tick</tt> and <tt>tickadj</tt>. This ensures that all 99275970Scyadjustments given to <tt>adjtime()</tt> are an even multiple of 100275970Scy<tt>tickadj</tt> microseconds and computes the largest adjustment that can 101275970Scybe completed in the adjustment interval (using both the value of 102275970Scy<tt>tick</tt> and the value of <tt>tickadj</tt>) so it can avoid exceeding 103275970Scythis limit. It is important to note that not all systems will allow 104275970Scyinspection or modification of kernel variables other than at system build 105275970Scytime. It is also important to know that, with the current NTP tolerances, it 106275970Scyis rarely necessary to make these changes, but in many cases they will 107275970Scysubstantially improve the general accuracy of the time service.</p> 108275970Scy<p>Unfortunately, the value of <tt>tickadj</tt> set by default is almost 109275970Scyalways too large for <tt>ntpd</tt>. NTP operates by continuously making 110275970Scysmall adjustments to the clock, usually at one-second intervals. If 111275970Scy<tt>tickaj</tt> is set too large, the adjustments will disappear in the 112275970Scyroundoff; while, if <tt>tickadj</tt> is too small, NTP will have difficulty 113275970Scyif it needs to make an occasional large adjustment. While the daemon itself 114275970Scywill read the kernel's values of these variables, it will not change the 115275970Scyvalues, even if they are unsuitable. You must do this yourself before the 116275970Scydaemon is started using the <tt>tickadj</tt> program included in the 117275970Scy<tt>./util</tt> directory of the distribution. Note that the latter program 118275970Scywill also compute an optimal value of <tt>tickadj</tt> for NTP use based on 119275970Scythe kernel's value of <tt>tick</tt>.</p> <p>The <tt>tickadj</tt> program can 120275970Scyreset several other kernel variables if asked. It can change the value of 121275970Scy<tt>tick</tt> if asked. This is handy to compensate for kernel bugs which 122275970Scycause the clock to run with a very large frequency error, as with SunOS 123275970Scy4.1.1 systems. It can also be used to set the value of the kernel 124275970Scy<tt>dosynctodr</tt> variable to zero. This variable controls whether to 125275970Scysynchronize the system clock to the time-of-day clock, something you really 126275970Scydon't want to be happen when <tt>ntpd</tt> is trying to keep it under 127275970Scycontrol. In some systems, such as recent Sun Solaris kernels, the 128275970Scy<tt>dosynctodr</tt > variable is the only one that can be changed by the 129275970Scy<tt>tickadj</tt> program. In this and other modern kernels, it is not 130275970Scynecessary to change the other variables in any case.</p> 131275970Scy 132275970Scy<p>We have a report that says starting with Solaris 2.6 we should leave 133275970Scy<i>dosynctodr</i> alone.</p> <p>In order to maintain reasonable correctness 134275970Scybounds, as well as reasonably good accuracy with acceptable polling 135275970Scyintervals, <tt>ntpd</tt> will complain if the frequency error is greater 136275970Scythan 500 PPM. For machines with a value of <tt>tick</tt> in the 10-ms range, 137275970Scya change of one in the value of <tt>tick</tt> will change the frequency by 138275970Scyabout 100 PPM. In order to determine the value of <tt>tick</tt> for a 139275970Scyparticular CPU, disconnect the machine from all source s of time 140275970Scy(<tt>dosynctodr</tt> = 0) and record its actual time compared to an outside 141275970Scysource (eyeball-and-wristwatch will do) over a day or more. Multiply the 142275970Scytime change over the day by 0.116 and add or subtract the result to tick, 143275970Scydepending on whether the CPU is fast or slow. An example call to 144275970Scy<tt>tickadj</tt> useful on SunOS 4.1.1 is:</p> 145275970Scy <pre> 146275970Scy <tt>tickadj</tt> -t 9999 -a 5 -s 147275970Scy</pre> 148275970Scywhich sets tick 100 PPM fast, <tt>tickadj</tt> to 5 microseconds and turns 149275970Scyoff the clock/calendar chip fiddle. This line can be added to the <tt 150275970Scy>rc.local</tt> configuration file to automatically set the kernel variables 151275970Scyat boot time. <p>All this stuff about diddling kernel variables so the NTP 152275970Scydaemon will work is really silly. If vendors would ship machines with clocks 153275970Scythat kept reasonable time and would make their <tt>adjtime()</tt> system 154275970Scycall apply the slew it is given exactly, independent of the value of 155275970Scy<tt>tickadj</tt>, all this could go away. This is in fact the case on many 156275970Scycurrent Unix systems.</p> 157275970Scy 158258945Sroberto<H3>Solaris 2.6</H3> 159258945Sroberto<P> 160258945SrobertoSolaris 2.6 adds support for kernel PLL timekeeping, but breaks this 161258945Srobertosupport in such a fashion that using it worse than not. This is <A 162258945SrobertoHREF="solaris.xtra.4095849"> SUN Bug ID 4095849</A>, and it is not yet 163258945Srobertofixed as of June 1998. 164258945Sroberto<P> 165258945Sroberto<H3>Solaris 2.5 and 2.5.1</H3> 166258945Sroberto<P> 167258945SrobertoOn UltraSPARC systems, calculation of <I>cpu_tick_freq</I> is broken 168258945Srobertosuch that values that are off by significant amounts may be used 169258945Srobertoinstead. This unfortunately means that ntpd may have severe problems 170258945Srobertokeeping synchronization. This is <A HREF="solaris.xtra.4023118"> SUN Bug ID 171258945Sroberto4023118</A>. Bryan Cantrill <! -- <bmc@eng.sun.com> --> of Sun 172258945Srobertoposted <A HREF="solaris.xtra.patchfreq">patchfreq</A>, a workaround script, 173258945Srobertoto comp.protocols.time.ntp in March of 1997. 174258945Sroberto<P> 175258945Sroberto<HR> 176258945Sroberto<H2>OLD DATA</H2> 177258945Sroberto<STRONG>I can't vouch for the accuracy the information below this 178258945Srobertorule. It may be significantly dated or incorrect.</STRONG> 179258945Sroberto<P> 180258945Sroberto<P> 181258945Sroberto<H3>Solaris 2.2</H3> 182258945Sroberto<P> 183258945SrobertoSolaris 2.2 and later contain completely re-written clock code to 184258945Srobertoprovide high resolution microsecond timers. A benefit of the 185258945Srobertore-written clock code is that adjtime does not round off its 186258945Srobertoadjustments, so ntp does not have to compensate for this 187258945Srobertorounding. Under Solaris 2.2 and later, ntp #define's 188258945Sroberto<CODE>ADJTIME_IS_ACCURATE</CODE>, and does not look for the <I>tickadj</I> 189258945Srobertokernel variable. 190258945Sroberto<P> 191258945Sroberto<H3>Solaris 2.1</H3> 192258945Sroberto(This originally written by William L. Jones <jones@chpc.utexas.edu>) 193258945Sroberto<P> 194258945SrobertoSolaris 2.1 contains fairly traditional clock code, with <I>tick</I> 195258945Srobertoand <I>tickadj</I>. 196258945Sroberto<P> 197258945SrobertoSince settimeofday under Solaris 2.1 only sets the seconds part of timeval 198258945Srobertocare must be used in starting xntpd. I suggest the following start 199258945Srobertoup script: 200258945Sroberto<BLOCKQUOTE><TT> 201258945Srobertotickadj -s -a 1000 202258945Sroberto<BR>ntpdate -v server1 server2 203258945Sroberto<BR>sleep 20 204258945Sroberto<BR>ntpdate -v server1 server2 205258945Sroberto<BR>sleep 20 206258945Sroberto<BR>tickadj -a 200 207258945Sroberto<BR>xntpd 208258945Sroberto</TT></BLOCKQUOTE> 209258945Sroberto 210258945SrobertoThe first tickadj turns of the time of day clock and sets the tick 211258945Srobertoadjust value to 1 millisecond. This will insure that an adjtime value 212258945Srobertoof at most 2 seconds will complete in 20 seconds. 213258945Sroberto<P> 214258945SrobertoThe first ntpdate will set the time to within two seconds 215258945Srobertousing settimeofday or it will adjust time using adjtime. 216258945Sroberto<P> 217258945SrobertoThe first sleep insures the adjtime has completed for the first ntpdate. 218258945Sroberto<P> 219258945SrobertoThe second ntpdate will use adjtime to set the time of day since the 220258945Srobertoclock should be within 2 seconds of the correct time. 221258945Sroberto<P> 222258945SrobertoThe second tickadj set the tick adjust system value to 5 microseconds. 223258945Sroberto<P> 224258945SrobertoThe second sleeps insure that adjtime will complete before starting 225258945Srobertothe next xntpd. 226258945Sroberto<P> 227258945SrobertoI tried running with a tickadj of 5 microseconds with out much success. 228258945Sroberto200 microseconds seems to work well. 229258945Sroberto<P> 230258945Sroberto<HR> 231258945SrobertoPrior versions of this file had major text contributed by: 232258945Sroberto<MENU> 233258945Sroberto<LI>Denny Gentry <denny@eng.sun.com> 234258945Sroberto</MENU> 235258945Sroberto<BODY> 236258945Sroberto</HTML> 237