Re: [PATCH] hpet: factor timer allocate from open

[john stultz]

On Mon, Mar 1, 2010 at 12:24 PM, Magnus Lynch <maglyx@xxxxxxxxx> wrote:
> Clemens Ladisch wrote:
>> A ioctl to read the main counter would just duplicate clock_gettime(),
>> but I cannot see any benefit over that.
>
> In fact for my situation I attempted using clock_gettime first and found it
> unsuitable. Specifically, my case is finding a substitute for RDTSC as a
> constant-rate counter for use in correcting real-time clock drift. This is for
> a CPU without constant TSC, as many are; and I was patching DJ Bernstein's
> excellent program clockspeed to be workable in such a case.
>
> Calculating the real time tick rate of clock_gettime using CLOCK_MONOTONIC
> suspiciously yielded a rate almost exactly 1GHz, which seemed to imply some
> feedback relative to real time was happening and thus wouldn't be reliably
> constant rate in the face of slewing the clock. Whatever the reason, in fact
> it wasn't and trying to depend on it as a constant rate timer while using
> adjtime quickly led to inaccuracies... Which led me to HPET as a solution,
> which worked swimmingly.
>
> I do now see there's another clockid, CLOCK_MONOTONIC_RAW, whose name implies
> it might work for me. I'll try it and see.

Yes, CLOCK_MONOTONIC_RAW was added specifically to create a hardware
agnostic interface that provided a 1:1 ratio to the hardware cycle
counter used by the timekeeping core. No NTP corrections or slewing
are applied and it isn't affected by settimeofday calls.

Let me know if you run into any trouble with it.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/