Very Computer

I'm not at all impressed by the accuracy of the clocks in these
Sun machines.  The /etc/ntp.drift file shows that each machine is
drifting by more than 110 ppm.

Machine         uname -rvm                      Drift   Machine
                                                (ppm)   Type

ngriffin        5.4 Generic_101945-27 sun4m     111.237 SS 20
amun            5.3 Generic_101318-70 sun4m     129.510 SS 20
smeagol         5.3 Generic_101318-59 sun4d     115.390 SC 2000

With drift values like these, xntpd is making time adjustments of
up to +/- 80 ms.  It seems to me that machines with this degree of
`jitter' are not suitable as servers for our entire campus.

In the xntp documentation it says that you can compensate for a
machine's drift by modifying the `tick' kernel variable with
tickadj.  (I had intended to set it in /etc/system.)  But the
Solaris 2.3 and 2.4 kernels have no variable named tick and so
tickadj complains.

Has anyone out there managed to successfully set up a Sol2 box as
an accurate time server?  Any help would be much appreciated.
--

Systems Programmer   Information Services   Griffith University

)>In the xntp documentation it says that you can compensate for a
)>machine's drift by modifying the `tick' kernel variable with
)>tickadj.  (I had intended to set it in /etc/system.)  But the
)>Solaris 2.3 and 2.4 kernels have no variable named tick and so
)>tickadj complains.

)>Has anyone out there managed to successfully set up a Sol2 box as
)>an accurate time server?  Any help would be much appreciated.

I asked a similar question here about a month or so ago with no reponse.
Does anybody know how to tweak clocks in Solaris 2.[34].
--
Bill Sebok      Computer Software Manager, Univ. of Maryland, Astronomy

Rick

/etc/system
......
*
* for xntpd see: tickadj(8)
*
set dosynctodr = 0
set nsec_per_tick = 10000600

Running the 'tickadj' program tells me that xntpd wants the corresponding
kernel variable set at 5 us, and that there are no such variable in the
(Solaris 2.x) kernel. The syslog from xntpd says the variable is set
to 625 us, which is much to large for xntpd to work well.

If Solaris 2.x really use a tickadj value of 625 us (and if that
can not be changed), xntpd really should know about the nsec_per_tick
kernel variable and use that one to slew the clock instead of
calling adjtime. Comments?

On the machines with Solaris 2.4 running xntpd 3.4o I am running,
xntpd is mostly able to keep the syncronisation in the 1-2 ms range
but occasionally (minutes to hours between) the offset jumps to 10-50 ms.
This I don't think can be made much better with the nsec_per_tick hack.

One machine with Solaris 2.3 (and earlier 2.2) have severe problems and
drops out of the (128ms?) window regularly. I suppose this machine could
be made to work as well as the 2.4's with the nsec_per_tick hack.

SunOS 4.1.x machines on the same local network have no problem keeping
the offset in the 1 ms range and under all the time.

(I use 2 ipx 4.1.x machines with local clocks only as servers since
this local network is isolated from the outside world.)

      _
Mats Lofkvist

  Solaris 2.x (x >= 2) does not round its adjtime() calls at all. In
  the xntp code this is what ADJTIME_IS_ACCURATE means. When you call
  adjtime(), Solaris applies 1/16 of the clock tick as correction on
  each tick until the last, when it applies the exact remaining amount.
  For example if the clock tick is 10 msec, and you call adjtime to
  slew the clock by 2 msec, on the next clock tick Solaris will adjust
  the clock by 10/16 = 1.6 msec, and the clock tick after it will apply
  exactly .4 msec.

  Other parts of xntp want to make calculations based on the value of
  'tickadj', so I fudged and said tickadj = tick/16, or 625 usec. But
  since ADJTIME_IS_ACCURATE is defined xntpd does not use the value of
  tickadj to determine the rounding, it knows there is no rounding.  In
  other words you should ignore tickadj claiming 625 usec and wanting 5
  usec, it is meaningless on Solaris (and Irix, and any other system
  with ADJTIME_IS_ACCURATE).

  The change is /etc/system to set nsec_per_tick is reasonable.

Quote:>On the machines with Solaris 2.4 running xntpd 3.4o I am running,
>xntpd is mostly able to keep the syncronisation in the 1-2 ms range
>but occasionally (minutes to hours between) the offset jumps to 10-50 ms.
>This I don't think can be made much better with the nsec_per_tick hack.

>One machine with Solaris 2.3 (and earlier 2.2) have severe problems and
>drops out of the (128ms?) window regularly. I suppose this machine could
>be made to work as well as the 2.4's with the nsec_per_tick hack.

  Also make absolutely sure that dosynctodr is set to 0 in /etc/system.

   [...]

   [...]

   >
   >One machine with Solaris 2.3 (and earlier 2.2) have severe problems and
   >drops out of the (128ms?) window regularly. I suppose this machine could
   >be made to work as well as the 2.4's with the nsec_per_tick hack.

     Are these by chance multiprocessor machines? If so, install the most
     recent kernel patch. There was a bug found in dealing with clock
     ticks on MP machines, it was possible for the clock interrupt to get
     taken twice which would jump the time ahead by 10 msec.

     Also make absolutely sure that dosynctodr is set to 0 in /etc/system.

I have had problems running NTP on Solaris 2.x MP SPARCs for about
half-a-year now.  At first NTP under Solaris 2.3 failed to work at all, but
after getting 101318-64 which fixes:

        1177620 gettimeofday doesn't work correctly when dual
                processors are used

the xntpd daemon works well enough, but seems to step time under heavy
load.  Since I need to more or less guarantee strictly monotonic
increasing time for database purposes, I can't use this.

Looking at the latest kernel patches for Solaris 2.[34], I can see no bug
fix that would seem to be related to clock interrupt.  Could you please
tell me which patch and/or bug id that you beliebe helped with your MP
Solaris machines?

--

"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

      Gentry) writes:

      [...]

      [...]

      >
      >One machine with Solaris 2.3 (and earlier 2.2) have severe problems and
      >drops out of the (128ms?) window regularly. I suppose this machine could
      >be made to work as well as the 2.4's with the nsec_per_tick hack.

        Are these by chance multiprocessor machines? If so, install the most
        recent kernel patch. There was a bug found in dealing with clock
        ticks on MP machines, it was possible for the clock interrupt to get
        taken twice which would jump the time ahead by 10 msec.

        Also make absolutely sure that dosynctodr is set to 0 in /etc/system.

   I have had problems running NTP on Solaris 2.x MP SPARCs for about
   half-a-year now.  At first NTP under Solaris 2.3 failed to work at all, but
   after getting 101318-64 which fixes:

           1177620 gettimeofday doesn't work correctly when dual
                   processors are used

   the xntpd daemon works well enough, but seems to step time under heavy
   load.  Since I need to more or less guarantee strictly monotonic
   increasing time for database purposes, I can't use this.

   Looking at the latest kernel patches for Solaris 2.[34], I can see no bug
   fix that would seem to be related to clock interrupt.  Could you please
   tell me which patch and/or bug id that you beliebe helped with your MP
   Solaris machines?

The machines I had the worst problems with were indeed MP machines.
One of them (with two 66 MHz HyperSparcs) stepped the time 10 ms forward
several times per hour. This problem went away when I installed the
latest 2.4 kernel patch. (There _is_ a note somewhere in the detailed
description of the patch that the clock interrupt could be taken twice
on MP machines.)

The worst deviation I see now is that a SS20/61 (2.4 with latest kernel patch)
moves in frequency a few ppm up and down in a sort of square-wave pattern
(with a cycle of a couple of hours). This makes the time off only a few
milliseconds though.
The other machines seems to move in frequency only by temperature changes
(rather nicely sinus shaped day/night cycles).

      _
Mats Lofkvist