Highspeed Timer(Counter)

[Pickle]

On the gp2x we had access to a timer with usec resolution. Does anyone have any information of a highspeed timer we can use on the wiz?
What ever SDL is uing seems unreliable.

 

[Exophase]

On the gp2x we had access to a timer with usec resolution. Does anyone have any information of a highspeed timer we can use on the wiz?
What ever SDL is uing seems unreliable.

Have you checked out with gettimeofday's returns are like? There's no reason why its precision should be sub-microsecond if the timers can provide that (and they can). Unless they did it wrong, which wouldn't be that surprising.

However, SDL is probably using gettimeofday too.

Are you certain you're referring to SDL_GetTicks and not SDL_Delay?

 

[Pickle]

On the gp2x we had access to a timer with usec resolution. Does anyone have any information of a highspeed timer we can use on the wiz?
What ever SDL is uing seems unreliable.

Have you checked out with gettimeofday's returns are like? There's no reason why its precision should be sub-microsecond if the timers can provide that (and they can). Unless they did it wrong, which wouldn't be that surprising.

However, SDL is probably using gettimeofday too.

Are you certain you're referring to SDL_GetTicks and not SDL_Delay?

I have not tried that function. And your right SDL_Delay may be the problem too.

 

[Franxis]

Why don't you use clock()?

clock_t wiz_timer_read(void)
{
    return clock(); /* CLOCKS_PER_SEC = 1000000 */
}

 

[Pickle]

Why don't you use clock()?

 clock_t wiz_timer_read(void)
 {
     return clock(); /* CLOCKS_PER_SEC = 1000000 */
 }

That I did try but it never worked right.

 

[notaz]

Have you checked out with gettimeofday's returns are like?

I've noticed earlier it returns "jumpy" values (sometimes subsequent reads have ~8ms time difference instead 0-1us like they should), so I did some investigation now. The problem with it is that it returns lower values then it should, the time "goes slower", then in every ~10ms it jumps to catch up. I can see where that ~10ms comes from (system timer interrupt).

The GP2X doesn't have such problem.

Why don't you use clock()?

clock_t wiz_timer_read(void)
{
    return clock(); /* CLOCKS_PER_SEC = 1000000 */
}

DESCRIPTION
       The clock() function returns an approximation of processor time used by the program.

This will be missing time spent in other processes and some in kernel, doesn't sound useful to me.

 

[Pickle]

One method that is working now on the wiz is to group 3 frames togther instead of one and only use SDL_ticks, and burn up the extra time in a while loop with SDL_ticks.
The key is that instead of 16 ms you use 50 ms which allows a smaller resolution than normally needed.
I plan to try it on lemonboy, but it looks pretty good.

 

[aho]

So, there isn't a timer which provides proper 1msec resolution? (1msec is good enough. It was good enough for Quake1/2/3 and it's certainly good enough for me.)

 

[Orkie]

There is. When I get back next week I will look and see if any of the precise hardware timers are free and write some code to use them if they are.

 

[notaz]

Only first of 5 POLLUX timers seems to be used by Linux, I've reprogrammed TIMER1 without any problems.

 

[Pickle]

Only first of 5 POLLUX timers seems to be used by Linux, I've reprogrammed TIMER1 without any problems.

Can you post any detail on how to use these timers?

 

[xteraco]

This thread reminds me of a portable high precision timer I wrote in C. If you're interested in seeing the code let me know.

 

[notaz]

Only first of 5 POLLUX timers seems to be used by Linux, I've reprogrammed TIMER1 without any problems.

Can you post any detail on how to use these timers?

For now I'll leave that for Orkie.

This thread reminds me of a portable high precision timer I wrote in C. If you're interested in seeing the code let me know.

It will still rely on some system calls, wouldn't it? The problem with Wiz is that those system calls don't return reliable data.

 

[xteraco]

The timer I have uses nothing other than C standard library. I've never tried using it anywhere other than Linux and M$ so I'm not 100% sure if it would work on the WiZ. I think it would though.

 

[Exophase]

I've noticed earlier it returns "jumpy" values (sometimes subsequent reads have ~8ms time difference instead 0-1us like they should), so I did some investigation now. The problem with it is that it returns lower values then it should, the time "goes slower", then in every ~10ms it jumps to catch up. I can see where that ~10ms comes from (system timer interrupt).

The GP2X doesn't have such problem.

This sounds very similar to a problem I've had in Linux for another platform. The problem there was that the time was being read inbetween when the timer wrapped around and when the jiffies counter updated. So the time was off by the HZ period. It was something like this

ticks, jiffies effective time
0 0 0
300 0 300
600 0 600
900 0 900
**timer interrupt hits, but result is either scheduled down further or delayed due to something stealing IRQ time
200 0 200
500 0 500
**jiffies are finally updated
800 1 1800

The solution in my case was to use a flag that the timer set to show that the IRQ had not been acknowledged.

I think whoever did the work on the Pollux Linux distro should probably never touch Linux again.

 

[Pickle]

I totally missed this, libcastor has a rtc support in it. It worked for nethack.

 

[Orkie]

That isn't the high precision timer, but clearly it is precise enough for what you are doing . I don't think the final Wizzes actually use it as an RTC (they have an external one or something, because the one built into the Pollux stops ticking if you shut it down) so you should be able to use it however you like.

 

[Pickle]

That isn't the high precision timer, but clearly it is precise enough for what you are doing . I don't think the final Wizzes actually use it as an RTC (they have an external one or something, because the one built into the Pollux stops ticking if you shut it down) so you should be able to use it however you like.

What resolution do you think this timer has? Anything that accurate to 1 ms is accurate enough.

 

[Orkie]

To be honest, I thought it only updated once a second. It has a 32.786kHz source, but that should be divided down to 1Hz. Your experience seems to suggest otherwise though?

 

[Pickle]

To be honest, I thought it only updated once a second. It has a 32.786kHz source, but that should be divided down to 1Hz. Your experience seems to suggest otherwise though?

Well i wasnt sure what resolution your gettime function returned, i assumed usec and i divided that to msec. It seems to work in nethack, although that isnt a really timing intensive game.