Re: TSC Timecounter and multi-core/SMP

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.