Timer accuracy

SDL Development
1

Is there any way in SDL to figure out how accurate (I.E. what granularity)
the timer functions give off? I’m trying to get something to an exact
frame rate and I’d like to incorporate any concept of overflow/rounding I
can to make it more consistent.

–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me

2

What about directly measure it? Something like

Uint32 samples[500];
Uint32 curTick;

curTick = SDL_GetTicks();
for(int i = 0; i < 500; ++i)
{
while(SDL_GetTicks() == curTick);

curTick = samples[i] = SDL_GetTicks();

}

Perhaps not perfect, but it could give you an idea.

MattOn Thursday 12 September 2002 07:24 pm, Neil Bradley wrote:

Is there any way in SDL to figure out how accurate (I.E. what granularity)
the timer functions give off?

3

Most are accurate to 10 msec, at least on the linux
platforms. To get an accurate frame rate for video
display, I’ve had to do a lot of work, and am still
mostly 4-5 msec off per frame.

Bill May
www.mpeg4ip.net

Neil Bradley wrote:> Is there any way in SDL to figure out how accurate (I.E. what granularity)

the timer functions give off? I’m trying to get something to an exact
frame rate and I’d like to incorporate any concept of overflow/rounding I
can to make it more consistent.

–>Neil

Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me

4

Why so fuzzy? On Linux, System.currentTimeMillis() in Java is accurate to 1ms.
I assume they both access the same timer?

MattOn Friday 13 September 2002 11:48 am, Bill May wrote:

Most are accurate to 10 msec, at least on the linux
platforms.

5

Yes, and no.

No hands-on Java experience, but I assume that System.currentTimeMillis()
corresponds to SDL_GetTicks() - in which case both should have 1 ms
accuracy on practically any platform. In fact, many platforms provide
better accuracy than that on the system API level.

However, very few operating systems support timers that can wake up
threads, send signals or something like that, with better than 10 ms
accuracy. This is because of OS scheduler design, and on some platforms,
there isn’t much to do about it. The scheduler checks software timers at
100 Hz, and that’s it.

That said, Win32 has “multimedia timers” that support 1000 Hz scheduling,
and Linux on virtually any PC or workstation (regardless of CPU) has the
RTC, which can be programmed to generate IRQs up to 8192 Hz.

Unfortunately, some Windows versions seem to have broken multimedia
timers IIRC, and you have to be root to set the Linux RTC rate higher
than 64 Hz. :frowning: Don’t know much about other platforms.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Saturday 14 September 2002 04:23, Matt Greer wrote:

On Friday 13 September 2002 11:48 am, Bill May wrote:

Most are accurate to 10 msec, at least on the linux
platforms.

Why so fuzzy? On Linux, System.currentTimeMillis() in Java is accurate
to 1ms. I assume they both access the same timer?

6

However, very few operating systems support timers that can wake up
threads, send signals or something like that, with better than 10 ms
accuracy. This is because of OS scheduler design, and on some platforms,
there isn’t much to do about it. The scheduler checks software timers at
100 Hz, and that’s it.

Won’t rising of HZ in the Linux kernel help timer accuracy?

latimeriusOn Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:
7

A good question indeed, Redhat 8.0 will ship with HZ=512 for i586, i686,
and Athlon systems…On Mon, 2002-09-16 at 05:35, Latimerius wrote:

Won’t rising of HZ in the Linux kernel help timer accuracy?

8

accuracy. This is because of OS scheduler design, and on some platforms,
there isn’t much to do about it. The scheduler checks software timers at
100 Hz, and that’s it.

For what it’s worth, this is going to change to 1000 (or maybe 1024 – I
forget) in the next release of the Linux kernel.

That said, Win32 has “multimedia timers” that support 1000 Hz scheduling,
and Linux on virtually any PC or workstation (regardless of CPU) has the
RTC, which can be programmed to generate IRQs up to 8192 Hz.

In order to access this, your program has to be run as root, though, right?On Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:

–
Matthew Miller @Matthew_Miller http://www.mattdm.org/
Boston University Linux ------> http://linux.bu.edu/

9

I don’t think it does, I think it just needs read/write access to
/dev/rtc, anyone?On Mon, 2002-09-16 at 09:10, Matthew Miller wrote:

In order to access this, your program has to be run as root, though, right?

10

Well, it should increase the resolution of “wake up/signal” style
timers, but as gettimeofday() normally uses the TSC when available,
that’s still theoretically accurate down to the ns range. (Not sure what
accuracy the interface actually allows.)

It does not make Linux any more of a real time OS, though. You should
get better average timing accuracy, but you need to take other, much more
drastic measures to do anything about worst case latency. (Something like
Linux/lowlatency and/or kpreempt. 2.6 will do it out of the box, it
seems, but for now, there are various patches for 2.2, 2.4 and 2.5.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 16 September 2002 12:35, Latimerius wrote:

On Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:

However, very few operating systems support timers that can wake up
threads, send signals or something like that, with better than 10 ms
accuracy. This is because of OS scheduler design, and on some
platforms, there isn’t much to do about it. The scheduler checks
software timers at 100 Hz, and that’s it.

Won’t rising of HZ in the Linux kernel help timer accuracy?

11

Interesting. It seems that increasing HZ can make desktop systems more
responsive, but I have no experience with that. (I’m more interested in
worst case than average latencies, and only lowlatency and kpreempt
patches can provide that.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 16 September 2002 15:52, DrEvil wrote:

On Mon, 2002-09-16 at 05:35, Latimerius wrote:

Won’t rising of HZ in the Linux kernel help timer accuracy?

A good question indeed, Redhat 8.0 will ship with HZ=512 for i586,
i686, and Athlon systems…

12

accuracy. This is because of OS scheduler design, and on some
platforms, there isn’t much to do about it. The scheduler checks
software timers at 100 Hz, and that’s it.

For what it’s worth, this is going to change to 1000 (or maybe 1024 –
I forget) in the next release of the Linux kernel.

Is this final? (Been out of the loop for a while…)

It’s about time, considering any current x86 chip has to be faster than
the Alphas that ran 1024 Hz back in the Pentium days, even when
considering the generally poor interrupt handling of the x86 arch…

That said, Win32 has “multimedia timers” that support 1000 Hz
scheduling, and Linux on virtually any PC or workstation (regardless
of CPU) has the RTC, which can be programmed to generate IRQs up to
8192 Hz.

In order to access this, your program has to be run as root, though,
right?

Yeah… until I, or some one else, gets fed up with it, and implements a
multimedia timer API with a system deamon to configure the RTC.

BTW, the 64 Hz limit is nothing but ridiculous, considering that just
about any sound card can be set up to generate well above 1000 IRQs per
second. It should have been changed to 1024 Hz long ago, IMHO.

Either way, giving non-root applications access to >64 Hz doesn’t really
solve anything, as the RTC would still be a non-sharable device. You
can’t really view it as a multimedia timer, as only one application at a
time can use it for that purpose.

So, the multimedia timer API that would solve the root issue, would be
needed anyway.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 16 September 2002 16:10, Matthew Miller wrote:

On Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:

13

Nope. You can use the RTC as soon as you have access to the device, but
the driver still prevents you from setting IRQ rates above 64 Hz, unless
you’re root.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 16 September 2002 16:30, DrEvil wrote:

On Mon, 2002-09-16 at 09:10, Matthew Miller wrote:

In order to access this, your program has to be run as root, though,
right?

I don’t think it does, I think it just needs read/write access to
/dev/rtc, anyone?

14

However, very few operating systems support timers that can wake up
threads, send signals or something like that, with better than 10 ms
accuracy. This is because of OS scheduler design, and on some
platforms, there isn’t much to do about it. The scheduler checks
software timers at 100 Hz, and that’s it.

Won’t rising of HZ in the Linux kernel help timer accuracy?

Well, it should increase the resolution of “wake up/signal” style
timers, but as gettimeofday() normally uses the TSC when available,
that’s still theoretically accurate down to the ns range. (Not sure what
accuracy the interface actually allows.)

The interface allows for microseconds iirc (struct timeval::tv_usec) and
at least on Linux/i386 microsecond resolution is actually used. But is
gettimeofday() useful for timers?

latimeriusOn Mon, Sep 16, 2002 at 04:37:42PM +0200, David Olofson wrote:

On Monday 16 September 2002 12:35, Latimerius wrote:

On Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:

15

However, very few operating systems support timers that can wake
up threads, send signals or something like that, with better than
10 ms accuracy. This is because of OS scheduler design, and on
some platforms, there isn’t much to do about it. The scheduler
checks software timers at 100 Hz, and that’s it.

Won’t rising of HZ in the Linux kernel help timer accuracy?

Well, it should increase the resolution of “wake up/signal” style
timers, but as gettimeofday() normally uses the TSC when available,
that’s still theoretically accurate down to the ns range. (Not sure
what accuracy the interface actually allows.)

The interface allows for microseconds iirc (struct timeval::tv_usec)
and at least on Linux/i386 microsecond resolution is actually used.

Right - and I guess you should get close even without a TSC, since main
board hardware timers are also independent of the OS and scheduler.
Should always be quite a bit better than 1 ms, I think.

But is gettimeofday() useful for timers?

No. (Unless you’re into busy-waiting hacks, while(…) yield(); looping
and that sort of stuff, that is.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Monday 16 September 2002 17:21, Latimerius wrote:

On Mon, Sep 16, 2002 at 04:37:42PM +0200, David Olofson wrote:

On Monday 16 September 2002 12:35, Latimerius wrote:

On Mon, Sep 16, 2002 at 10:20:47AM +0200, David Olofson wrote:

16

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Monday 16 September 2002 18:05, David Olofson wrote:

On Monday 16 September 2002 17:21, Latimerius wrote:

The interface allows for microseconds iirc (struct timeval::tv_usec)
and at least on Linux/i386 microsecond resolution is actually used.

Right - and I guess you should get close even without a TSC, since main
board hardware timers are also independent of the OS and scheduler.
Should always be quite a bit better than 1 ms, I think.

The PIT’s internal frequency is used when no TSC is available, and that is
just above 1MHz (don’t know the exact number right now) so yes, that’s a
lot better than 1ms precision.

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9hhVJsxPozBga0lwRAt9WAKCKWPEhhLc9rLphGYuZQ6/flyieeACZAaay
/SZ5gaKoDY0TnEufnC7Ez54=
=W2GP
-----END PGP SIGNATURE-----

17

Please take this off-list and post a summary with conclusions.
There are lots of threads on this in the archives.

Thanks. :slight_smile:
-Sam Lantinga, Software Engineer, Blizzard Entertainment