debbieg@smokey.sandiego.NCR.COM (06/11/91)
> 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
rbthomas@frogpond.rutgers.edu (Rick Thomas) (06/12/91)
% 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.
One way to speed up the synchronization process (so it only takes a
couple of days, not a couple of months) is to up the value of the
window size for synchronization (CLOCK_MAX_F) in ntp.h .
One value that will work (and the one I use) is
#define CLOCK_MAX_F 0x5999999a /* 350 ms, in time stamp format */
The comments indicate that the maximum that will work without major
code changes is
#define CLOCK_MAX_F 0x7ffffffe /* 499 ms, in time stamp format */
But I stick with the slightly smaller value because I'm superstitious
about pushing boundary conditions.
Rick