From owner-cvs-all Mon Nov 30 10:50:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26965 for cvs-all-outgoing; Mon, 30 Nov 1998 10:50:37 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26947; Mon, 30 Nov 1998 10:50:30 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id TAA12848; Mon, 30 Nov 1998 19:48:12 +0100 (CET) To: Matthew Dillon cc: Peter Wemm , 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> Date: Mon, 30 Nov 1998 19:48:11 +0100 Message-ID: <12846.912451691@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message <199811301805.KAA00788@apollo.backplane.com>, Matthew Dillon writes: > 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. We do just that. > 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 do just that. > 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. We do just that, unless it is a SMP, in which case we would need to synchronize the TSC of the cpus before we can use them. (If only Intel hadn't yanked the timer from the IO-APIC!) > 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). We do much better than just that: 1e-9/2^32 ~= 2.32e-19 Then we could implement this so all the complexity is in the machine independent part of the kernel, with only a trivial procedure to read the counter in the machine-dependent part. We do just that. And we should be using auto-atomic data structures so we avoid as many disable/enable/locking operations as we can. We do just that. It should also support blindingly fast routines to get a timestamp which is reasonably current, for frequent operations where the absolute precision is not important. We do just that. And it should enable us to timestamp external events with arbitrary high precision and to steer the clock gracefully instead of slamming it around every hardclock(). We do just that. And it should be resistant to grossly broken interrupt delivery. Now we do just that, if people set the sysctl "kern.timecounter.method=1" And it should be documented in a paper how this thing works, including measurements to prove at least some of the above claims. I'm working on that. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message