Very Computer

I've noticed that the drift values for ultras running solaris 251
are always reporting pretty hi, always over 100 ppm & sometimes > 200.
The old tricks that work for, say, sparc 5's running solaris 251
don't work, as has been discussed here in the past.

Are these drift numbers meaningful?  

: I've noticed that the drift values for ultras running solaris 251
: are always reporting pretty hi, always over 100 ppm & sometimes > 200.
: The old tricks that work for, say, sparc 5's running solaris 251
: don't work, as has been discussed here in the past.

: Are these drift numbers meaningful?  

Howdy,
   Meaningful depends on your syslog and personal
needs.  If your xntpd is running ok, you still have
much better time than without ntp.

   As you noted, the trim of the clock in /etc/system
is reported to not work in Ultra's and x86 versions of
Solaris 2.5x.  I use 2.5 on non-ultra sparc and have
trimmed to +/- 2 ppm.  Why?  Because I can, I'm a geek,
and it helps smooth out the clock and reduce the number
of adjtime calls.

   In the SunOS 4.1 world, "tickadj -s -t xxxxx allows
t* to +/- 50 ppm, since it's microsecond granularity.

   With the warning that I'm no guru, just another chime-
head, I'd like to have my ntp machines trimmed.  With a
200 ppm drift, xntpd is making a 0.2 ms adjtime every second.
I think the adjtime happens over ten to twenty ticks, so
the clock runs a bit rough.  Since the adjtime has a limited
amount of adjustment avaiable, a large drift makes your host
nearer to discovering that the "adjustment didn't complete"
or even not being able to keep the clock under control,
which would cause frequent "steps".  Watch syslog.

   If you are using time for precision where fractions of
ms might make a difference, this might be important.  If
your syslog doesn't show "steps" or "didn't complete"
often and the accuracy is within your needs, I think your
drift isn't a problem.  With a correct .../ntp.drift file,
your host should be able to wake up fairly quickly and
(as I understand xntpd) xntpd will keep making the drift
adjustment even when it looses its servers, so your
un-synched time should hold on as well as a trimmed host.
Without its own .../ntp.drift, your host will have a longer
period learning its drift after each reboot.

   The future might hold some hope.  I've seen that Solaris
2.6, due out 1997 (spring I think), is rumored to have ntp
in the distribution.  I hope that this will convince Sun to
make the changes needed to trim or to allow the kernel type
adjustments to handle the poor clocks found in some Sun
hardware and the even worse clocks found in many PCs.
I think linux has a new system call that works (adjtimex ?).

Summary: If it runs without many "steps" and you aren't
         doing anything mondo detailed about time, relax
         and enjoy.  Short of replacing the hardware, what
         can you do anyway?

usual disclaimers apply

----- attached /etc/system lines for ntp on my sparc -----

For anybody that hasn't seen them elsewhere, here are the
lines I've added to my Solaris 2.5 sparc (non-Ultra)
/etc/system.  These are only examined on boot up.
Lines starting with * are comments.  Save the original !

* Changes to sparc solaris 2.5 /etc/system for Network Time Protocol
* Remove if xntp is taken off this host.
* 1) Set the system variable dosynctodr to 0 to disable the system
*    from calling adjtime to keep the system clock to the hardware
*    clock/calendar chip.  xnptd will control clock now.
set dosynctodr = 0
* 2) Adjust the nsec_per_tick variable to trim the clock frequency.
*    After xntpd has been running smoothly, I averaged ome of the
*    drifts.  A reported drift of +132.5 parts per 2^20 makes a
*    change of +1264 added to the default 10000000 nsec_per_tick.
*    Sign of drift:  + means local clock is slow so add nsec each tick.
*       set nsec_per_tick to 10^7 + (drift * 9.537)
*    I think the first try should get to within a few ppm.
*    This trick came from the comp.protocols.time.ntp newsgroup.
*    Reported to NOT work on x86 and Ultra 2.5x versions.
set nsec_per_tick = 10001264
* end of xntp section

[Michael Helm]

|   I've noticed that the drift values for ultras running solaris 251
|   are always reporting pretty hi, always over 100 ppm & sometimes > 200.
|   The old tricks that work for, say, sparc 5's running solaris 251
|   don't work, as has been discussed here in the past.
|  
|   Are these drift numbers meaningful?  

. and I have an Axil Ultima 1 here (167 MHz Ultrasparc) with drift
values of 700 or more :-(  Lots of 'Previous time adjustment incomplete'
and 'time reset (slew)' in the logs.