From owner-cvs-all Tue Dec 1 16:19:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11313 for cvs-all-outgoing; Tue, 1 Dec 1998 16:19:54 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (ppp3.portal.net.au [202.12.71.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11305; Tue, 1 Dec 1998 16:19:50 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA06826; Mon, 30 Nov 1998 16:39:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812010039.QAA06826@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon cc: Peter Wemm , Poul-Henning Kamp , Mike Smith , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_clock.c In-reply-to: Your message of "Mon, 30 Nov 1998 10:05:41 PST." <199811301805.KAA00788@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Nov 1998 16:39:32 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > Someone tell me if I'm missing something here: Why aren't we simply > scaling (at least for the higher-end cpu's) the 64 bit cycle counter > register? It seems simple enough to me. It's frequency needs to be > calculated but it should be reasonably stable once that is done and > there are *no* overflow problems. Because the TSC is tied to the CPU clock, which is not guaranteed to be constant (any system with power management will change the CPU clock). It's erroneous to use the TSC other than in exceptional circumstances on the i386. I don't know of any Alpha systems that dink the clock, so the relationship between their cycle counter and real time is more definite. > That is, use the standard timer interrupt to generate hardclocks, but > base all time operations off the scaled 64 bit cycle counter for cpu's > that support it. We would *not* use the 82C54's timer registers to > actually try to read out the counter at all unless we were running on > much older cpu's. Unfortunately, the i8254 is the only thing in the system that can be expected to run at more or less the rate you set it to. > If we dynamically scale the 64 bit counter down to 32 bits and guarentee > a scaling factor that guarentees us at least 1 hour @ 32 bits before > rollover, we still have a resolution of 0.838 uS (or, at worse using > a power-of-2 scaling, 1.6 uS). > > Seems dandy to me! It would, until the TSC starts varying in speed. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message