From owner-cvs-src@FreeBSD.ORG Mon Apr 7 01:58:32 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22F7C37B401; Mon, 7 Apr 2003 01:58:32 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C502043F85; Mon, 7 Apr 2003 01:58:30 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h378w7Zq004146; Mon, 7 Apr 2003 10:58:13 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 07 Apr 2003 17:55:54 +1000." <20030407163148.L3478@gamplex.bde.org> Date: Mon, 07 Apr 2003 10:58:07 +0200 Message-ID: <4145.1049705887@critter.freebsd.dk> cc: src-committers@FreeBSD.org cc: Nate Lawson cc: cvs-src@FreeBSD.org cc: Tor.Egge@cvsup.no.freebsd.org cc: cvs-all@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 tsc.c src/sys/i386/conf NOTES X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2003 08:58:32 -0000 In message <20030407163148.L3478@gamplex.bde.org>, Bruce Evans writes: Sorry Bruce, but this is a fair bit more complicated than that. It is true that the temperature coefficient of the RTC crystal and the crystal which (usually) drives the i8254 and TSC are different, but we are nowhere close to being able to measure that in a one second interval with the kind of jitters we suffer in accessing the RTC. If we did many observations or used longer integration times, we might be able to improve it, but it is certainly not something we can even contemplate waiting for during bootup. Once we have booted, NTPD beats anything we can do (see below before protesting about lack of network connectivity). >Another thing the old code got right was calibration of the i8254 relative >to the TSC. They obviously use the same hardware clock on at least >all of my active machines (BP6, A7V266-E), since the calibrated ratio >is always the same (as far as ntp running over a long period can tell). This is generally true, and while the Xtal is normally the 14.318MHz[1] neither are universal facts. I played with detecting the actual PLL ratios, and this generally is a viable avenue under the normal circumstances, but sufficient "odd-ball" systems exist that I am not comfortable with it in general. >The old calibration code calibrates them relative to another clock so >the only error in their relative frequencies is from the different time >that it takes to read their counters. The i8254 counter typically takes >5 usec longer to read, but for some reason the actual error is less than >1 i8254 cycle on all of my active systems. That is because the i8254 access is synchronized to the "virtual" ISA bus frequency and your CPU is much faster than that. The best result I have had so far, and the only one I have sufficient faith in to advocate its use in general, takes an entirely different route: The RTC interrupts us at 128Hz for statclock, divide this in software to get 1Hz and take timestamps and feed them to the NTP kernel-FLL code and tell NTPD to lock to that at a high stratum. This will synchronize the clock to the RTC frequency. It may be possible to detect the RTC second roll-over and feed absolute timestamps to the NTP kernel-PLL code to also synchronize to the RTC in phase. Poul-Henning [1] fun fact: The 14.318MHz is four times the color burst frequency of NTSC television signals, and was chosen by IBM for the original IBM PC because it made it possible to generate four different colors in a purely digital fasion on a television connected to the CGA. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.