🚀 go-pugleaf

> deleted..
> 
> Now the strange thing--  `poll' seconds after the local machine has
> synchronized to a peer, all dispersions start over with a value of 63.5
> or 64.0 again, and the synchronization is (therefore) lost.
> 
> deleted..
>
> Regards,
> --
> Oliver Laumann         net@tub.cs.tu-berlin.de       net@tub.UUCP
> 

I waited to see if the were any responses from SUN users, but since I
have not seen a response, I thought I would tell you that I have seen a 
similar occurrence in our local network.  

We have a network of 25mhz and 33mhz (NCR System 3000 System V.4) machines.  
The network is isolated (not synchronized to UTC) but all machines sync to 
the time on one server which is 33mhz.  All 33mhz machines quickly become 
in sync but the 25mhz machines would show the same signs as you described.  
The reset of the dispersion is caused by the ntp_loopfilter code which checks
to see if the offset is greater than 128 milliseconds.  If it is,
then the step_systime code is called.  If the time is stepped, the
clock_update function (in ntp_proto) resets all registers (which sets 
dispersion to max).  

The offsets for the 25mhz machines generally ran from .300 to .100 so
they generally did not stay in sync.  After the network had been
up about a month, I looked at a couple of the 25mhz machines and found
that the were in sync.  What was different about them is that they had
accumulated a frequency (or drift) value of about 1.97 to 2 whereas the 
drift of the other machines was generally less than 0.2.  I am not
sure how long it took for these systems to come to the correct frequency
(could be a week to a month).  Anyway, now all systems are
synchronized.

I'm not sure if my solution is your solution because of the different
machine types, but hopefully, it is helpful in giving you an understanding
on what is happening.

Debbie

Debbie.Galeazzi@SanDiego.NCR.COM
NCR E&M - San Diego, California