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
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310628.RAA11546>