Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!neptune.rutgers.edu!frogpond.rutgers.edu!rbthomas From: rbthomas@frogpond.rutgers.edu (Rick Thomas) Newsgroups: comp.protocols.time.ntp Subject: Re: Malfunctioning xntpd on Sun workstation Message-ID: Date: 11 Jun 91 22:32:03 GMT References: <9106102055.aa26067@ncrcom.DaytonOH.NCR.COM> Distribution: inet Organization: Rutgers Engineering Supercomputer Lab Lines: 29 Cc: rbthomas % 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