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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:15 EST