Re: [PATCH] improved boot time TSC synchronization

[Jim Houston <jim.houston@attbi.com>]

Jamie Lokier wrote:
> 
> Is it reasonable to repeat the test over a duration of 10^6 cycles (or
> more) such that you could detect any drift after synchronisation, as
> well as variation _during_ that time interval?
> 
> I'm thinking of those spread spectrum clocks, which I gather are done
> by frequency modulating the clock.  It may be possible to detect:
> 
>         (a) whether multiple CPUs with spread spectrum clocks are
>             actually locked to each other, or if the modulation
>             of each is independent
> 
>         (b) whether multiple CPUs are drifting w.r.t. each other
>             because of independent clock sources
> 
> Although drift tends to be small, it should be possible to determine
> "these clocks drifted by <1ppm during the test interval", which is a
> pretty good indication of whether it is safe to use the TSC for
> gettimeofday() or not.
> 
> -- Jamie

Hi Jamie,

These are problems I haven't run into yet. All of the systems
I have stay nicely locked once they are in sync. It might be fun
to try this experiment if someone who has a system with this 
problem volunteered to test.

For systems where the cpu frequency may vary I like the idea of
still using the TSC but doing a software phase locked loop to 
synchronize it to another timer.  I believe that Linus suggested 
this as well.  At least he suggested an NTP like approach.
The code necessary to do this could detect properly synchronized
TSCs and avoid most of the work.

Jim Houston - Concurrent Computer Corp.