From: Tony Houghton on
What can I use for accurately measuring elapsed time in C code? I'm
looking for round about millisecond accuracy. I've written some code to
wait for vsyncs using OpenGL, but while glXGetRefreshRateSGI reports a
consistent 59Hz, measuring the time between two syncs with gettimeofday
results in a period corresponding to anything up to 88Hz, although it
does seem to usually give 59.8802.

I tried clock(), but that doesn't return anything useful.

Most video players seem to use /dev/rtc but I can't find useful
documentation about it. The kernel docs suggest that the way it's used
is that you program it with the frequency you want it to generate
interrupts (requiring root access for >64Hz, so that's a problem for a
start). Wouldn't that affect the whole machine? What if two applications
want to use it at the same time, at different frequencies? And the clock
can be disturbed by its being kept in sync with external sources etc.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.
From: Bruce Stephens on
Tony Houghton <this.address.is.fake(a)realh.co.uk> writes:

> What can I use for accurately measuring elapsed time in C code? I'm
> looking for round about millisecond accuracy. I've written some code to
> wait for vsyncs using OpenGL, but while glXGetRefreshRateSGI reports a
> consistent 59Hz, measuring the time between two syncs with gettimeofday
> results in a period corresponding to anything up to 88Hz, although it
> does seem to usually give 59.8802.

> I tried clock(), but that doesn't return anything useful.

Have you tried gettimeofday?

[...]

From: Tony Houghton on
On Sat, 02 Sep 2006 22:37:50 +0100
Bruce Stephens <bruce+usenet(a)cenderis.demon.co.uk> wrote:

> Tony Houghton <this.address.is.fake(a)realh.co.uk> writes:
>
> > What can I use for accurately measuring elapsed time in C code? I'm
> > looking for round about millisecond accuracy. I've written some code to
> > wait for vsyncs using OpenGL, but while glXGetRefreshRateSGI reports a
> > consistent 59Hz, measuring the time between two syncs with gettimeofday
> > results in a period corresponding to anything up to 88Hz, although it
> > does seem to usually give 59.8802.
>
> > I tried clock(), but that doesn't return anything useful.
>
> Have you tried gettimeofday?

Yes. That's the one I said was sometimes reading in 59.8802Hz, but also
returning times way outside the expected values.

--
The address in the Reply-To is genuine and should not be edited.
See <http://www.realh.co.uk/contact.html> for more reliable contact addresses.
From: Bruce Stephens on
Tony Houghton <this.address.is.fake(a)realh.co.uk> writes:

> On Sat, 02 Sep 2006 22:37:50 +0100
> Bruce Stephens <bruce+usenet(a)cenderis.demon.co.uk> wrote:
>
>> Tony Houghton <this.address.is.fake(a)realh.co.uk> writes:
>>
>> > What can I use for accurately measuring elapsed time in C code? I'm
>> > looking for round about millisecond accuracy. I've written some code to
>> > wait for vsyncs using OpenGL, but while glXGetRefreshRateSGI reports a
>> > consistent 59Hz, measuring the time between two syncs with gettimeofday
>> > results in a period corresponding to anything up to 88Hz, although it
>> > does seem to usually give 59.8802.
>>
>> > I tried clock(), but that doesn't return anything useful.
>>
>> Have you tried gettimeofday?
>
> Yes. That's the one I said was sometimes reading in 59.8802Hz, but also
> returning times way outside the expected values.

OK, sorry, it's right there in the text I quoted. Don't know, then.
It seems surprising that that doesn't give millisecond resolution.

I seem to remember some discussion. Ah, google refers to a LWN
article on kernel support, <http://lwn.net/Articles/167897/>. Not
directly useful, I guess. Also
<http://high-res-timers.sourceforge.net/>, which looks much more
useful, presuming it works with recent kernels.
From: Bruce Stephens on
Bruce Stephens <bruce+usenet(a)cenderis.demon.co.uk> writes:

[...]

> Also <http://high-res-timers.sourceforge.net/>, which looks much
> more useful, presuming it works with recent kernels.

Ah, not useful, probably. That appears to be what's in librt, which
(on my kernel, anyway, which has the default setting of 250 for
CONFIG_HZ) claims to give 4ms resolution. I guess you could get 1ms
resolution by using a kernel with CONFIG_HZ set to 1000? Would that
be good enough?