Hi,
Interesting observation and wondered if anyone knew firstly why this has happened and secondly how I can get round it...

I have a couple of timers running - installed via:

if ( install_int_ex(timer_proc, BPS_TO_TIMER(16)) < 0 ) etc...

Anyway this updates a counter so that in the main loop I can flash a small 'alive' rectangle on-screen...

Now I have recently installed ntpd (network time protocol daemon) and when the date/time gets updated (usually after about a minute or so after startup), the timer_proc() function no longer gets called...

Any comments/ideas?

Kev

EDIT:
Have got around this by incrementing an fps counter in the main loop and resetting it in the timer.. in the main loop I detect when this counter exceeds an expected range and reinstall the timers if this happens.

Still wonder what's happening though...

EDIT2:
Mmmm.... re-installing the timers doesn't work...

Just how far off does your clock get? Might want to allow your distro/OS to set the clock on shut down, or get a new motherboard battery so it remembers the time

Also, try remove_timer(); then install_timer(); when reinitializing timers. Due to the way I seem to remember allegro timer's working, allegro registers ONE single os timer, and keeps track of time to handle fireing off individual user timers.

What? I thought that every OS used the programmable timer that gets set on boot up from the battery-backed real time clock. The one you had to enter the time every boot on the original PC because it didn't have a real time clock. The one that DJGPP reprogrammed for finer granularity.

If your mobo battery is dead, the RTC on the mobo won't run when the machine is off, and will loose time.

But the time intervals will still be the same.

If allegro does its timing using absolute time values, then if the clock gets changed far enough, it may never get caught up.

Once the boot process is complete, the motherboard timer runs at the correct rate, although not matched up to the wall clock.

Not talking about the bios or the os. But Allegro itself. On windows its implemented in a thread that runs at a specific rate, and fires off installed timers. If its using the time from the OS to manage the timers, a large change in time will cause bad things to happen.

On Windows, doesn't it use QueryPerformanceCounter, which in turn uses the Pentium cycle count? Nothing to do with timer chips at all.

That would make it depend on the speed of the cpu would it not?

What I'm saying is, if the time gets set via ntp, it'll skew the clock, which allegro may be using to know when to fire off timers. Not saying thats what is actually happens, just a possibility.

That's what QueryPerformanceFrequency() is for. Or you mean the Cool'n'Quiet thing? I think Windows adjusts for that with some sort of hook.

the performance counter is not run at a fixed speed. The faster the cpu, the faster it increments afaik.

Also, took a look at the unix timer driver for allegro 4.4. It uses gettimeofday, so if the clock was set back far enough, it seems like it would indeed stop running user timers till the time caught up. Though I'm not sure what select would do on a negative sleep period

I remember a couple of years ago this computer wouldn't keep a charge on the CMOS battery so I removed the battery altogether and set the time and optimized defaults every time I powered it up. It ran fine until the next time it was powered down for 30 seconds or more. Eventually it turned out to be a bad stick of RAM.

Yes, hence QueryPerformanceFrequency(). That gives you the frequency at which the performance counter increases.

I have a box here that does a similar thing. The battery never goes dead, though after the PSU stops applying standby power to the mobo, it will lose its settings. That box has no video card in it either at the moment, so I'm very careful that it keeps power. It's sitting on a UPS and is configured to shut down conservatively, giving it plenty of time to remain powered to ride out all but the longest outages.

Wow..! Thanks for the replies guys

I'll have a look at removing the timer first (probably a very sensible idea!) using remove_int().

Note this is on a small LX800 processor board running my hacked linux kernel and it has no built-in battery - hence why I'm using NTP...

The first time-update from NTP is effectively 7 years(!) so can understand it could have a detrimental effect on the timer when it changes. Could have looked at the timer routines in allegro, but thought asking the question here would be easier and more interesting.

Interestingly enough in my tests, this problem only manifests itself 30% of the time..

Will report in a moment back with success/failure of removing the timer first - thought it would be unnecessary as allegro would just overwrite the previous timer, which in hindsight was very naive of me..!

As far as I know allegro will just change the timer's freq if you give it the same timer function again. At least thats how I seem to remember it

Yeah, that was what I'd expected... maybe it was working - but have added the remove_int() call just in case and also tidied up some other code wrt displaying the date/time and all appears okay after 6 resets...