From owner-cvs-all Wed Dec 29 6:39:30 1999 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 06C22151B1; Wed, 29 Dec 1999 06:39:28 -0800 (PST) (envelope-from phk@FreeBSD.org) Received: (from phk@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id GAA19053; Wed, 29 Dec 1999 06:39:27 -0800 (PST) (envelope-from phk@FreeBSD.org) Message-Id: <199912291439.GAA19053@freefall.freebsd.org> From: Poul-Henning Kamp Date: Wed, 29 Dec 1999 06:39:27 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern kern_ntptime.c Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk phk 1999/12/29 06:39:27 PST Modified files: sys/kern kern_ntptime.c Log: Don't use time_offset as a leaky bucket variable in hardpps(), this resulted in vastly optimistic offset values reported to userland (typically a factor 40+ too small). Apart from that, the code had two sign-bugs. Apply the hardpps() phase with the right sign with a simply scaling by integration interval. (This may be too stiff at long integration intervals, see below). Allow pps_shiftmax to be reduced again. Before this, the phase lock in hardpps() were broken, but due to two bugs mostly cancelling out, it would end up basically working with a large stochastic component. Now it behaves as one would expect: smooth and quiet. It seems that pps_shiftmax above 7..9 somewhere makes the phaselock too weak to hold onto random walk phase errors from a HP-105 OCXO, which basically means that it is too weak for real-life use with such integration times. This is yet to be resolved. Submitted to: Prof. Dave "NTP" Mills. Tested by: Terje Mathisen Revision Changes Path 1.30 +18 -15 src/sys/kern/kern_ntptime.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message