Date: Sat, 19 Apr 2008 07:15:04 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@freebsd.org Subject: Re: TSC Timecounter and multi-core/SMP Message-ID: <20080418211504.GH73016@server.vk2pj.dyndns.org> In-Reply-To: <200804181930.m3IJUUYx026599@apollo.backplane.com> References: <51610.1208498408@critter.freebsd.dk> <4808E06D.8020304@elischer.org> <200804181930.m3IJUUYx026599@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Fri, Apr 18, 2008 at 12:30:30PM -0700, Matthew Dillon wrote:
> I think it's harder then it sounds. The technology isn't difficult,
> the problem is the two requirements people seem to have for a solid
> time base these days:
>
> * Fast access time (in-instruction-stream)
> * High resolution (~1nS)
> * Not eat up a bunch of die area or current
On this last point, just building a 64-bit counter that runs at
roughly the CPU clock speed and can be accurately read is non-trivial
- a simple ripple-carry counter is probably good for about 4 bits.
By the time you add all the carry propagation circuitry, you probably
have quadrupled the die area and increased the power consumption by
2 orders of magnitude - though this is still trivial compared to the
complete CPU core.
To the above list, I'd add:
* Counters read by different CPU (potentially on different dies) can
be correlated - ie same count rate and fixed count offset.
* Wide enough that the software doesn't have to worry about overflows
(ie around 64 bits)
> If one didn't mind foregoing the high resolution requirement then
> the problem is greatly simplified... an external time base, such as
> a 1-30 MHz crystal, can be fed into just one bit's worth of
> resynchronization logic to generate counter pulses at the cpu's operating
> frequency and the counter can then be implemented inside the cpu,
> synchronized to its operating frequency.
This sounds like a cheap-to-read version of the ACPI-fast counter.
The idea sounds reasonable. Now all you need is to convince a vendor
to implement it :-)
> It kind of turns into a mess no matter how you twist it, as long as
> the 'fast access time' requirement is left in place.
Agreed. And without fast access time, high resolution is meaningless.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)
iEYEARECAAYFAkgJD1gACgkQ/opHv/APuIcSWACglETeBHXYCnPramvqrduT3NrQ
xMgAoJso8I6LVD989ugn7rjvEJOPPEG2
=RmO1
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080418211504.GH73016>