From owner-freebsd-current Sun Feb 11 02:07:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA26748 for current-outgoing; Sun, 11 Feb 1996 02:07:15 -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 CAA26740 for ; Sun, 11 Feb 1996 02:07:03 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA04514; Sun, 11 Feb 1996 21:04:46 +1100 Date: Sun, 11 Feb 1996 21:04:46 +1100 From: Bruce Evans Message-Id: <199602111004.VAA04514@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.tfs.com Subject: Re: calibrating clocks Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> I plan to calibrate all the system clocks relative to the MC14618A (RTC) >> clock and perhaps use the results automatically. Sample results on a >> P133 for a sequence of calibrations run at boot time: >Did you see the email about the "almost correct sub-tic" stunt ? >Basically you count how many times microtime was called per tick, >make a (short) running avg of it, and when people call microtime >you just return the tick + a counter times that avg. >For most if not all purposes this would be cheap and OK. Actually >only high-precision profiling and NTP would need any better... I don't think it's OK. It would be too inaccurate to use in mi_switch(), which seems to be the only place where its overhead is noticeable. One of the microtime() calls in mi_switch() could be avoided if the context switch is immediate. The i586 clock is good enough for the sub-tick count. Even if it varies, it can be rescaled often. The i8254 clock probably needs to be read on i586's every clock tick to determine the latency of hardclock(). The cost of this is < 5usec * 100 Hz = 500 usec/sec = 0.05%. Bruce