Date: Sun, 31 Dec 1995 17:28:23 +1100 (EST) From: michael butler <imb@scgt.oz.au> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-current@freebsd.org, peter@haywire.dialix.com Subject: Re: Tick, tock, adjust the clock Message-ID: <199512310628.RAA11546@asstdc.scgt.oz.au> In-Reply-To: <199512310503.QAA17446@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 04:03:21 pm
index | next in thread | previous in thread | raw e-mail
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, michaelhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310628.RAA11546>