Date: Mon, 30 Nov 1998 10:05:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, 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: <199811301805.KAA00788@apollo.backplane.com> References: <199811301508.XAA11566@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
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!
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
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?199811301805.KAA00788>