Re: ia64 clock_gettime and HP_TIMING

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen <jes@trained-monkey.org> said:

  Ulrich> The HP clocks are extremely useful.  They stay.

  Jes> I am not saying that should go, I am just asking we come up
  Jes> with a solution that means our binaries return an error rather
  Jes> return unreliable data.

  Jes> How do you feel about a solution where we add a runtime check
  Jes> against /proc/sal/itc_drift and handle it appropriately within
  Jes> the HP_TIMING macros?

All platforms with drifting cycle-counters have a common
(CPU-external) high-precision timer, so shouldn't you be using that
instead of returning an error?

I didn't get Uli's point about gettimeofday() not being sufficiently
accurate, though.  True, the current light-weight gettimeofday() does
only ITC-based interpolation (and falls back on heavy-weight syscall
otherwise), but that still gives rather high precision
(sub-microsecond, at least).  Moreover, I don't see any reason why the
light-weight system call couldn't be extended to support HPET and
perhaps SGI's timer (since they never seem to use standardized
hardware... ;-/ ).  Whether or not the resulting gettimeofday() would
be sufficient for HP_TIMING purposes, I don't know.

	--david