problem with using SLEEPQQ

[kristien]

Hello,

I'm trying to use the SLEEPQQ function in a program, but it want sleep for the exact time a ask. Every 200 ms he has to calculate a loop, that takes for example 4 ms, the remaining time (196ms) he has to wait, but it has to be exact 196ms, because the program is running in realtime for a simulator for ships.

I wrote a testprogram, just to test the SLEEPQQ function and it gives very odd results. This is my testprogram (trying to wait 100x20ms :

T1 = MILI_CLOCK(.FALSE.)

do i=1,100

call SLEEPQQ(20)

enddo

T2 = MILI_CLOCK(.FALSE.)

write (*,*) 'time waited after 100 x = ms :',T2-T1

I expect the result to be 2000, but it gives 3126, WHY???, I don't ask anything else to do but waiting....

Please can anyone help me with this problem.

ThX a lot!

[Steven_L_Intel1]

The Windows API used by SLEEPQQ does not provide the resolution you want. I suggest that you look at the Win32 API (MSDN) documentation for "Multimedia timers" - that may be a better approach.

[garylscott1]

Quoting - Steve Lionel (Intel)

The Windows API used by SLEEPQQ does not provide the resolution you want. I suggest that you look at the Win32 API (MSDN) documentation for "Multimedia timers" - that may be a better approach.

How about a future improvement to SLEEPQQ to use a higher resolution timer? I've resorted to installing a discrete I/O board so that I can read a 32-bit 1 microsecond timer (can only read it in 7 microseconds tho on my machine).

[Steven_L_Intel1]

SLEEPQQ uses a low-overhead and common method which suffices for most applications. Higher resolution (and higher overhead) timers are available to developers.

[garylscott1]

Quoting - Steve Lionel (Intel)

SLEEPQQ uses a low-overhead and common method which suffices for most applications. Higher resolution (and higher overhead) timers are available to developers.

Yup, it still looks like the APIs specify a maximum of 1 millisecond. For data acquisition, I need at least 1 microsecond resolution timers (and wait accuracy of around 15 microseconds). I seem to be able to get that with my add-on board.

[Steven_L_Intel1]

The standard APIs are based on the OS's internal interrupt timer which typically fires at 1ms (or in the past, 10ms) intervals. Greater resolution requires an add-on board as you have found.

[GVautier]

Hello

Have you tried the Windows API timer that send you a "message" at a fixed interval?

[jimdempseyatthecove]

Gary

If you are running on a Windows system at application level you will not reliably wakeup at 1 or 15 micro second precision. A device driver may attain this resolution. Your best bet for reliability is to use a programmable interval timmer (add-on card) that you program to signal at the desired frequency. In this manner the signal event occures at the "precise" time interval which then causes a chain of events (programmable timer fires -> interrupt service -> device driver signals Windows -> Windows schedular queues application -> application wakes up). Note, although your application will not wake up precisly at the tick, the more important factor is that you will not observe tick creep (i.e. you "clock" won't run slow). The beginning of the chain of events is consistant.

At application level you have a problem when you code

a) get time now
b) compute time to next interval
c) sleep until next interval

When your application experiences a Windows context switch after step a) and before the suspension in step c) you will not wake up at the desired time.

Jim Dempsey

[garylscott1]

Quoting - jimdempseyatthecove

Gary

If you are running on a Windows system at application level you will not reliably wakeup at 1 or 15 micro second precision. A device driver may attain this resolution. Your best bet for reliability is to use a programmable interval timmer (add-on card) that you program to signal at the desired frequency. In this manner the signal event occures at the "precise" time interval which then causes a chain of events (programmable timer fires -> interrupt service -> device driver signals Windows -> Windows schedular queues application -> application wakes up). Note, although your application will not wake up precisly at the tick, the more important factor is that you will not observe tick creep (i.e. you "clock" won't run slow). The beginning of the chain of events is consistant.

At application level you have a problem when you code

a) get time now
b) compute time to next interval
c) sleep until next interval

When your application experiences a Windows context switch after step a) and before the suspension in step c) you will not wake up at the desired time.

Jim Dempsey

Yes, I use an add-on board that has 3 16bit interval timers. These can be ganged together to gain additional depth, but at the expense that it takes longer to read the timer value, about 7usec for each byte. The support procedure is a device driver set, but it appears as simple procedure calls to my app. I can assign callback procedures as well. Suprisingly simple to use. It provides 24 reconfigurable discretes as well (they have cards with 120 or so I think, but didnt' need it for this project). I use it to correlate various hardware signals with serial bus data (echo on bus, synchronization, recording)