🚀 go-pugleaf

Paul at NCF wrote:
 >
 > I've got a timer system that uses GetTickCount for calculate the
 > number ticks (in milliseconds), for timer calculations etc.
 >
 > This works fine on my laptop, which is quite a good HP running XP.
 > But on the target system running NT and is a lower spec PC, its not
 > accurate at all; usually timers are 10-20% longer (eg. A 15 second
 > timer ends up being about 18).

Are you doing something like this?

... {
    SetTimer( NULL, 0, 15000, TimerProc );
}

TimerProc(..., dwTime ) {
     static DWORD dwLastTime=0;
     SetTimer( NULL, 0, 15000, TimerProc );

     if( dwLastTime ) {
         /*
         dwTime - dwLastTime
         should now be approx. 15000, unless a wrap around occured,
         but you get 18000 ?
         */
     }
     dwLastTime = dwTime;
}

 > I've tried using the performance counter as a more accurate system,
 > but I'm not getting very good results even on my HP.
 >
 > Has anyone got any clues or ideas for a timer calculations for
 > handling timers of various lengths?

I used QueryPerformanceCounter() and QueryPerformanceFrequency() a few 
years back to measure RPM's in an engine (connected to a pin in the 
serial-port on a Windows NT4 box). We test-fed the application up to 
something like 300000 pulses/s (~0.003 ms between pulses) which it 
measured quite nicely.

> PS.  my perception of accuracy is based on the Now() time logged in a file 
> activitie (hours,mins,secs,milliseconds).

Hmmm, may we see some code?

Kind regards,
Ted Lyngmo

Ted Lyngmo wrote:

>Are you doing something like this?
>
>... {
>    SetTimer( NULL, 0, 15000, TimerProc );
>}
>
>TimerProc(..., dwTime ) {
>     static DWORD dwLastTime=0;
>     SetTimer( NULL, 0, 15000, TimerProc );

Just to let you know, that isn't needed, and can introduce drift.
The Timer normally continues firing until killed.
This code will reset the timer-start-time after an unknown message processing delay.

Bob Gonder wrote:
 >Ted Lyngmo wrote:
 >
 >>... {
 >>   SetTimer( NULL, 0, 15000, TimerProc );
 >>}
 >>
 >>TimerProc(..., dwTime ) {
 >>    static DWORD dwLastTime=0;
 >>    SetTimer( NULL, 0, 15000, TimerProc );
 >
 > Just to let you know, that isn't needed, and can introduce drift.
 > The Timer normally continues firing until killed.
 > This code will reset the timer-start-time after an unknown message
 > processing delay.

True, my bad!

Cheers,
Ted

Thanks for your help, I'll look into other options for doing timing. 
However, I did find a bug in my handling of the tick counter, which does 
explain some of the drift.  I'm in the process of testing the change on the 
target system.

Thanks

Paul


"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:qoupg31jr5jp4jmpf6bmor22kj1s1361gu@4ax.com...
> Ted Lyngmo wrote:

Hi,

I found a bug in the timer handler, and since I've fixed it, its all working 
much better.

Thanks for any help.

"Paul at NCF" <notplmacca@clara.co.uk> wrote in message 
news:4709d350@newsgroups.borland.com...
> Hi,
>
> This works fine on my laptop, which is quite a good HP running XP.  But on
> the target system running NT and is a lower spec PC, its not accurate at 
> all;