From owner-freebsd-current  Wed Dec 27 16:11:42 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA27015
          for current-outgoing; Wed, 27 Dec 1995 16:11:42 -0800 (PST)
Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA27010
          for <current@freebsd.org>; Wed, 27 Dec 1995 16:11:40 -0800 (PST)
Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id TAA07038 for current@freebsd.org; Wed, 27 Dec 1995 19:11:15 -0500
Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id JAA16464; Wed, 27 Dec 1995 09:47:32 -0500
Date: Wed, 27 Dec 1995 09:47:32 -0500
From: Gene Stark <gene@starkhome.cs.sunysb.edu>
Message-Id: <199512271447.JAA16464@starkhome.cs.sunysb.edu>
To: peter@haywire.dialix.com (Peter Wemm)
Cc: current@freebsd.org
In-reply-to: peter@haywire.dialix.com's message of 27 Dec 1995 11:08:52 +0800
Subject: Re: Tick, tock, adjust the clock
References: <199512261708.LAA14134@miller.cs.uwm.edu> <4bqic1$e6g@starkhome.cs.sunysb.edu>
Sender: owner-current@freebsd.org
Precedence: bulk

>>These step adjustments are extremley annoying to programs that run
>>and clock things in the 10ms range.  The clock jumps forward and
>>backward like a jumping bean.  If I discontinue running xntpd my
>>time adjustment problems go away, but then my clock doesn't keep
>>correct time.
>
>>Any ideas or fixes?  Any good starting places to start hacking away to fix
>>this?
>
>I've had the same problem for quite some time..  On all the
>FreeBSD machines I have access to, the xntpd oscilates very very badly
>(like you've shown) and eventually logs "not logging any more time
>steps" or something like that.

I solved this problem (on 486 systems) by using tickadj to adjust the value
of "tick" a few notches off of its standard value of 10000.  The values I had
to use were obtained by trial and error, and are different on each system.
For example, I recall having to use values like 9994 instead of 10000.
I also use a driftfile to avoid the lengthy resync period when the system
is rebooted.

Changing the tick value causes the system time to increment at a different
rate.  This gets the drift rate of the clock into a region where
xntpd can sync to it with slew adjustments rather than step adjustments.

I still have a nagging suspicion that there is a problem with the timekeeping
code, since on forty-some systems I never had to use a tick value above
10000, only below.  This suggests systematic bias, probably in software.
However at one point Bruce Evans assured me that he believed the stuff was
working correctly, so I haven't investigated further.

							- Gene Stark