From owner-freebsd-current Sat Dec 30 22:28:55 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA10264 for current-outgoing; Sat, 30 Dec 1995 22:28:55 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA10259 for ; Sat, 30 Dec 1995 22:28:48 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id RAA11546; Sun, 31 Dec 1995 17:28:24 +1100 From: michael butler Message-Id: <199512310628.RAA11546@asstdc.scgt.oz.au> Subject: Re: Tick, tock, adjust the clock To: bde@zeta.org.au (Bruce Evans) Date: Sun, 31 Dec 1995 17:28:23 +1100 (EST) Cc: freebsd-current@freebsd.org, peter@haywire.dialix.com In-Reply-To: <199512310503.QAA17446@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 04:03:21 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Peter Wemm writes: > >tick = 10000 us, tickadj = 40 us > >calculated hz = 100.00 Hz > >recommended value of tickadj = 5 us > >And after a few days of running, behold! It has locked in! > >... > >The question is.. what have I done? :-) Have I simply made the kernel > >respond to adjtime() faster? The "tickadj" value is one of the seed values to determine how far xntpd can slew the clock in a 2 second interval. Consistent errors, as you've discovered, beyond this slew rate will result in the fall-back method of clock stepping :-( Essentially, what is being done by changing "tickadj" is to broaden the PLL's capture range at the expense of clock jitter. Bruce Evans writes: > I think you just made it possible for adjtime() to work. One of my > clocks has a drift of about 7 parts in 10000, so a tickadj of 5 couldn't > possibly work for it. If the clock is precise but inaccurate by this factor, then changing the "tick" variable is possibly a better option in that it preserves the clock's precision without incurring significant additional jitter (as raising "tickadj" does). > I still think the best fix involves changing TIMER_FREQUENCY. There > is no official mechanism for doing this, but it can be fiddled with > fairly easily: Which achieves a similar net effect to changing the "tick" variable. In your example, "tickadj -Aq -t 9993" will probably do the trick without source code changes (assuming it's "wrong" in that direction, most PCs are :-(). Note that you must restart xntpd after playing with these. You know when you've hit the best "tickadj" value when /etc/ntp.drift is consistently indicates a drift of less then +/- 128 after a few days of "settle time". My comments above are based on the assumption that you have a consistently low latency link to your chosen clock reference(s). PPP links, particularly busy ones, rarely have this characteristic and alterations to "tickadj" may be preferable in that case, michael