From owner-freebsd-stable Tue Mar 3 17:54:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20002 for freebsd-stable-outgoing; Tue, 3 Mar 1998 17:54:03 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19869 for ; Tue, 3 Mar 1998 17:53:21 -0800 (PST) (envelope-from louie@whizzo.TransSys.COM) Received: from whizzo.TransSys.COM (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.8/8.7.3) with ESMTP id UAA27608; Tue, 3 Mar 1998 20:52:24 -0500 (EST) Message-Id: <199803040152.UAA27608@whizzo.TransSys.COM> X-Mailer: exmh version 2.0.1 12/23/97 To: Warner Losh cc: Dennis Tenn , Scot Elliott , stable@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: xntp messages in new build References: <199802202230.PAA18268@harmony.village.org> In-reply-to: Your message of "Fri, 20 Feb 1998 15:30:30 MST." <199802202230.PAA18268@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Mar 1998 20:52:23 -0500 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > In message Dennis Tenn writes: > : | Feb 20 15:34:16 uranus xntpd[16462]: Previous time adjustment didn't > : | complete > : > : All it means AFAIK is it couldn't connect to the time server to update the > : clock. This happens on my system too and you shouldn't worry about it. > > No. That's not quite right. It means that the last adjustment (via > tickadj) didn't finish slowly skewing the clock before the next one > was requested. I've seen this mostly when there is a largish offset > at the start. You can ignore these messages if you have a couple, but > thery may indicate something wrong with your hardware (or that of the > time server) if you get lots of them. Under normal circumstances, you shouldn't see this out of a clock adjustment that NTP makes. If you are, there are two likely possibilities: - Some other process (like timed?) did a tickadj() system call, and when the xntpd daemon did it's adjustment, it's seeing the residual delta. - The value of "tick" in the kernel is inconsistant with what xntpd is prepared to deal with. Possibly the "tickadj" program can correct this. Generally, xntpd will perform a series of adjustments to gently slew the clock; it's won't crank in more clock slew per interval than it believe the kernel can actually adjust. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message