From owner-freebsd-current Mon Jun 10 19:42:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA12781 for current-outgoing; Mon, 10 Jun 1996 19:42:17 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA12774 for ; Mon, 10 Jun 1996 19:42:13 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA08156; Tue, 11 Jun 1996 12:40:59 +1000 Date: Tue, 11 Jun 1996 12:40:59 +1000 From: Bruce Evans Message-Id: <199606110240.MAA08156@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@sri.MT.net Subject: Re: CLOCK stuff at bootup Cc: current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >> The i8254 clock determines long term accuracy. Run for a while and >> >> determine the drift and/or the time daemon adjustments. >> >> >How? >> >> Compare the output of `date` with an accurate clock or look in the time >> deaemon log files. >And how would I do that? I'm not sure what kind of 'drift' I'm >expecting. >(Forgive me, but I'm not clock expert, nor do I understand what all of >this buys me if I have to hand-set all of these variables.) Then don't ask. The defaults work the same as before. >> >> Use sysctl to >> >> specify the i8254 clock frequency that minimizes the drift and/or the >> >> >How? >> >> Look in the output of `sysctl -a` to find the relevant variable and set >> it as usual. >machdep.i8254_freq: 1193182 >This was set at bootup time already, so how do I determine what to set >it to except via trial and error. The boot messages give another possible values. Otherwise, use trial and error. >> >> The i586 clock determines intra-clock-interrupt times. Specify the i586 >> >> clock frequency that minimizes the jitter in getttimeofday(). >> >> >How? >> >> First find the frequency. Set it as above. >machdep.i586_freq: 0 Nothing set it, so it remains at 0. >Set it to the stuff that was kicked out by the kernel? Why isn't aren't >these values already set by default? Because they are relative to the mc146818A clock, which is not known to be a better reference point than the i8254 clock (it probably is, but a sample size of 3 or 4 systems is not enough to decide). Bruce