zook@sweetpea.jsc.nasa.gov (Craig A. Zook x4206) (03/25/91)
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-4206linegar@bwdls49.bnr.ca (Derick Linegar) (03/26/91)
zook@sweetpea.jsc.nasa.gov (Craig A. Zook x4206) writes: >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. This keep coming up, so here is a message that tries to explain some workaround for this [in]famous message: (BTW, the adb trick works for me, I haven't had that beelming message since....) -derick- Included message: From comp.protocols.time.ntp Tue Feb 26 08:14:54 1991 Newsgroups: comp.protocols.time.ntp Path: bwdls61!bnrgate!cunews!hobbit.gandalf.ca!ddrg From: ddrg@hobbit.gandalf.ca (Duncan Glendinning) Subject: Re: Previous time adjustment didn't complete? Message-ID: <1991Feb25.201510.7422@hobbit.gandalf.ca> Keywords: Previous time adjustment complete Organization: Gandalf Data Ltd. References: <1991Feb23.223034.13241@hoss.unl.edu> Distribution: na Date: Mon, 25 Feb 1991 20:15:10 GMT Lines: 34 In <1991Feb23.223034.13241@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes: > I got three messages today like: >Feb 23 12:59:40 sardion xntpd[96]: Previous time adjustment didn't complete > What was the explanation about why this happens? I'm sorry for >asking this because it was answered several weeks ago before I got xntpd >running. I didn't pay attention then, and now all of those messages are >gone from our news host. > About the same time as these 3 messages a program was running which >really sucked up the system resources. I'm on a Sun SLC under 4.1.1 of >the operating system. I have never seen these messages before, and >xntpd seems to running just fine. Thanks for any explanation. In the `Daemons and Dragons' column of one of the Unix Mags (Unix World?), there is an article written by someone at Sun regarding SunOS 4.1 and clock synchronization. After following his instructions, I eliminated or SunOS 4.1 and 4.1.1 problems. Here are the instructions, (from Unix World, Vol. 8, Number 12, page 62), which turns off the kernel variable to disable the software clocks from synchronizing to the hardware clock: # adb -k -w /vunix /dev/mem dosynctodr/D ./W0 ./D0 .?W 0 .?D 0 -- Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca Gandalf Data Ltd. Voice: (613) 723-6500 Nepean, Ontario Fax: (613) 226-1717 Canada K2E 7M4 From comp.protocols.time.ntp Tue Feb 26 08:15:20 1991 Path: bwdls61!bnrgate!cunews!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!maverick.ksu.ksu.edu!hoss!sardion!mosemann From: mosemann@sardion.unl.edu (Russell Mosemann) Newsgroups: comp.protocols.time.ntp Subject: Re: Previous time adjustment didn't complete? Keywords: Previous time adjustment complete Message-ID: <1991Feb25.232209.26116@hoss.unl.edu> Date: 25 Feb 91 23:22:09 GMT References: <1991Feb23.223034.13241@hoss.unl.edu> <1991Feb25.201510.7422@hobbit.gandalf.ca> Sender: news@hoss.unl.edu (Network News Administer) Distribution: na Organization: University of Nebraska - Lincoln Lines: 35 In <1991Feb25.201510.7422@hobbit.gandalf.ca> ddrg@hobbit.gandalf.ca (Duncan Glendinning) writes: >In <1991Feb23.223034.13241@hoss.unl.edu> mosemann@sardion.unl.edu (Russell Mosemann) writes: >> I got three messages today like: >>Feb 23 12:59:40 sardion xntpd[96]: Previous time adjustment didn't complete >> What was the explanation about why this happens? [..] >which turns off the kernel variable to disable the software clocks >from synchronizing to the hardware clock: > # adb -k -w /vunix /dev/mem > dosynctodr/D > ./W0 > ./D0 > .?W 0 > .?D 0 >-- >Duncan Glendinning CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca >Gandalf Data Ltd. Voice: (613) 723-6500 >Nepean, Ontario Fax: (613) 226-1717 >Canada K2E 7M4 Hmmm. That can't be it. I put 'tickadj -Aqs' in my rc.local so that the tick value is automagically calculated and changed, and the value of dosynctodr is set to zero every time the system is rebooted. -- Russell Mosemann Internet: mosemann@crcvms.unl.edu Network Analyst Bitnet: mosemann@unlvax1 Computing Resource Center UUCP: ..!uunet!hoss.unl.edu!mosemann University of Nebraska - Lincoln Voice: (402) 472-5930 Fax: 472-5280 -- #include <disclaimer.h> Derick Linegar, Internet Systems 4P27, Bell-Northern Research Internet: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: Discontinued, due to lack of credit. Ottawa ONT. K1Y 4H7