From owner-freebsd-current Sat Dec 30 21:05:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA07551 for current-outgoing; Sat, 30 Dec 1995 21:05:00 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA07536 for ; Sat, 30 Dec 1995 21:04:37 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA17446; Sun, 31 Dec 1995 16:03:21 +1100 Date: Sun, 31 Dec 1995 16:03:21 +1100 From: Bruce Evans Message-Id: <199512310503.QAA17446@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, peter@haywire.dialix.com Subject: Re: Tick, tock, adjust the clock Sender: owner-current@freebsd.org Precedence: bulk >Well, I've found an answer that totally cures it for us.. I increased >the 'tickadj' rate from 5us to 40us.. ie: tickadj -a 40 >pwroot@gecko2[3:35am]~-101# tickadj >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? 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. tickadj = 40 was the default in FreeBSD-1.1.5. The `recommended' value above is based on 5 being the largest reasonable amount of drift for a `tick' of 10000 (except on RS6000's, which apparently live in a universe with different universal constants :-). 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: - write a slightly different value to timer_0_max_count in /dev/kmem - access pcaudio to get the new value written to the clock hardware. Bruce