Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!eos!aio!sweetpea!zook From: zook@sweetpea.jsc.nasa.gov (Craig A. Zook x4206) Newsgroups: comp.protocols.time.ntp Subject: xntpd problem on Sun SPARC 1 Keywords: xntpd adjtime Message-ID: <1991Mar25.083340@sweetpea.jsc.nasa.gov> Date: 25 Mar 91 14:33:39 GMT Sender: news@aio.jsc.nasa.gov (USENET News System) Reply-To: zook@sweetpea.jsc.nasa.gov (Craig A. Zook x4206) Organization: nasa-jsc Lines: 44 I have be attempting to use the xntpd program from louie.udel.edu. I had no trouble installing it on a Sun 4/280. But when I tried to install it on a Sun 4/60 (SPARC 1) it did not work correctly. The first problem is that the program generates several hundred messages to the syslog. A sample follows: Mar 25 07:46:29 odessa xntpd[2358]: Previous time adjustment didn't complete Mar 25 07:53:25 odessa last message repeated 14 times Mar 25 07:53:57 odessa xntpd[2358]: Previous time adjustment didn't complete Mar 25 07:58:57 odessa last message repeated 10 times Mar 25 07:59:25 odessa xntpd[2358]: Previous time adjustment didn't complete Mar 25 08:06:25 odessa last message repeated 14 times Mar 25 08:06:57 odessa xntpd[2358]: Previous time adjustment didn't complete When I run "xntpdc -c peers" I see that the requested adjtime is not always taking place. As a matter of fact the offset is as likely to increase as to decrease. The net result is that the clock accuracy is about .2 seconds as opposed to the > .02 second I get on the 4/280. My best guess is that the when the Previous time adjustment does not complete the next time adjustment messes things up. It also seems likely the the root problem is that the SPARC 1 can not complete an adjtime in under 4 seconds. From the man pages for adjtime it says: The adjustment is effected by speeding up (if that amount of time is positive) or slowing down (if that amount of time is negative) the system's clock by some small percentage, gen- erally a fraction of one percent. Thus, the time is always a monotonically increasing function. A time correction from an earlier call to adjtime() may not be finished when adj- time() is called again. No where does it mention how long it should take to slew the clock. By the way, the error messages can be suppressed by commenting out line 357 in the program ntp_unixclock.c and remaking xntpd. If anyone has a solution to this problem please let me know. -- Craig Zook - zook@sweetpea.jsc.nasa.gov Systems Engineeering and Administration McDonnell Douglas Space Systems Corp. - Engineering Services Division (713) 283-4206