Re: Timer patch V8

[Christoph Lameter <clameter@sgi.com>]

On Thu, 9 Sep 2004, Alex Williamson wrote:

> On Thu, 2004-09-09 at 08:28 -0700, Christoph Lameter wrote:
> > On Thu, 9 Sep 2004, Alex Williamson wrote:
> >
> > > On Wed, 2004-09-08 at 16:23 -0700, Christoph Lameter wrote:
> > > > Sorry. I was too superficial when looking at this issue. The following
> > > > patch makes the hpet driver build again but I do not have a machine here
> > > > that would allow me to test this. Could you verify that this works and get
> > > > back to me?
> > > >
> > >
> > >    It builds and boots, so a definite improvement.  I'm not sure how to
> > > check if the hpet is being used though.  Thanks,
> >
> > Could you run the following program and sent me the output? The precision
> > of the REALTIME clock should be the same as the HPET device.
> >
>
> The program reports:
>
>           Gettimeofday() = 1094745228.671790000
>            CLOCK_REALTIME=     -17032.000003664 resolution= 3648.000238936
>           CLOCK_MONOTONIC=     -17032.000003664 resolution= 3648.000238936
>  CLOCK_PROCESS_CPUTIME_ID=          0.000714263 resolution= 0.000000001
>   CLOCK_THREAD_CPUTIME_ID=          0.000723913 resolution= 0.000000001
>
>
> The HPET driver reported a 4ns tick on the timer.  Thanks,

Sorry but the data is useless. You might be running a glibc build with
2.4.X headers. The values for CLOCK_REALTIME and CLOCK_MONOTONIC are wrong and
the same. CLOCK_REALTIME should be >1000000000 (same as gettimeofday) at
this point whereas CLOCK_MONOTONIC should reflect uptime. If glibc is
build with 2.4.X headers then it will improvise these clocks. That maybe
happening.

If you have a 4ns tick then the resolution should be 0.000000004.