Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen <jes at trained-monkey dot org>]

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:

>>>>> 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> 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?

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

Can you point me to some specs for that and I'll take a look at
cooking up a patch?

David> Moreover, I don't see any reason why the light-weight system
David> call couldn't be extended to support HPET and perhaps SGI's
David> timer (since they never seem to use standardized
David> hardware... ;-/ ).  Whether or not the resulting gettimeofday()
David> would be sufficient for HP_TIMING purposes, I don't know.

I'll see what I can come up with patch wise for something that allows
the HP_TIMING to be flagged as available/unavailable runtime as well
as supporting the HPET (if I can find info about it somewhere). Should
be pretty easy to setup something the first time get_clockfreq() is
called. Not knowing enough about HPET, my biggest worry is if we have
to open up an extra file descriptor for a permanent mmap of it.

Cheers,
Jes