Date: Mon, 30 Nov 1998 19:48:11 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@netplex.com.au>, Mike Smith <mike@smith.net.au>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_clock.c Message-ID: <12846.912451691@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 30 Nov 1998 10:05:41 PST." <199811301805.KAA00788@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12846.912451691>