Hi,
I am using an Asus EEEPC 901.
(Atom 270, 1GB RAM, 16GB Flash, WinXP, GCC 4, A5 4.9.11)
The a5 timer example runs uneven and slower than expected.
I noticed that the timer al_current_time() represents runs too slow...
One second of al_current_time() lasts nearly for two seconds in rl.
Are there known issues running a5 timers on Intel Atom 270 ?
Can someone imagine what is going wrong here?

I just noticed that I'm not using an up-to-date version of a5. But there didn't changed so much concerning timers. Nevertheless I will change to 4.9.12 as soon as I'm home again.

Thx

The implementation is in src/win/wtime.c (low_res_current_time, high_res_current_time). I would check how the underlying functions perform outside of Allegro. The code hasn't changed for ages so updating Allegro won't make a difference.

The inaccuracy of the timer has been pointed out before. I wonder if it is something wrong with the implementation. It has been noted to be wrong on all platforms.

I suspect again that this is an issue related to assuming that ticks/seconds remains constant throughout a program's execution, and grows monotonically. This is not the case for multicore systems or system that automatically downstep processor frequency (like the eee).

Hmm, but which processor doesn't do that any more?

Still, you might be right. Can whoever suffers from this problem try to disable the "high_res" timer in wtime.c? It does look a bit dodgy. It's just a small edit to the _al_win_init_time() function.

I tried searching the forums for that sub-bitmap vs. regular bitmap thread but I couldn't find it. The code in that thread didn't work right for me IIRC.

Presumably that was in response to something else..

There are at least two timer chips in a PC that have nothing to do with CPU frequency. The frequencies of these are far in excess of what a game demands...

If possible update the BIOS for your eee pc...
It could be problem AAG25 (or AAG34) for Intel Atom N270 Stepping C0 processors... If the timer works the way I think it does then this could be it...

Quote from http://download.intel.com/design/processor/specupdt/320047.pdf

AAG25 Split Locked Stores or Locked Stores Through Certain Segments May
not Trigger the Monitoring Hardware

Problem: Logical processors normally resume program execution following the MWAIT, when
another logical processor performs a write access to a WB cacheable address within
the address range used to perform the MONITOR operation. Due to this erratum, a
logical processor may not resume execution until the next targeted interrupt event or
O/S timer tick following a locked store within the monitored address range that either
spans across cache lines or uses a segment register whose segment base is noncacheline
aligned.

Implication: The logical processor that executed the MWAIT instruction may not resume execution
until the next targeted interrupt event or O/S timer tick in the case where the
monitored address is written by a locked store which is either split across cache lines
or through a segment whose segment base bits 5 to 0 are non-zero.
Workaround: Avoid accessing the monitored address range using either locked stores that split
cache lines or locked stores that use a segment with a non-cacheline aligned segment
base. It is possible for the BIOS to contain a workaround for this erratum

Status: For the steppings affected, see the Summary Tables of Changes.

Sure. The problem is that certain methods of measuring time, such as RDTSC and, more oddly, QueryPerformanceCounter (which is odd because QPC is explicitly intended NOT to be subject to the RDTSC issue -- this is mainly a problem, I think, because MSDN's documentation outright lies to you on one critical point), still suffer from the problem and are very commonly used. Not knowing what A5 uses for its high-performance timing, I can't say which one it is; but for timing purposes, anything that relies on CPU clock frequency is no longer an accurate way to do it.