Time Resolution

[Lance Edmonds]

JFYI, according to MSDN, CreateWaitableTImer(), SetWaitableTimer(), etc, is 98/NT/2000-only... Win95 does not support it.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Brian, I think you can perform a test using QueryPerformanceCounter()
to determine when a second has elapsed while updating an array of longs
with the ms value from GetSystemTime after QueryperformanceCounter()
has determined each ms has elapsed.

You should get 1000 different values for the ms member of getSystemTime().

Have you looked at CreateWaitableTimer/SetWaitAble timer? I think they can
use APC's. SetWaitableTimer has 100ns resolution.


------------------
Ron

[Scott Turchin]

I wrote an NIST time function a while back, and then one to MIMICK an NIST time server (Impossible on an Intel board)...

NIST allocates a 50ms delay into the time, you are still responsible for measuring network delay and whatnot of course and doing the math.

Based on that, I haven't found a need to get below 1ns just yet.
I've got it down to between 50ms and 150ms depending on the network delay.

Be happy to post if if interested, uses QuadTime to measure the accuracy.


Scott


------------------
Scott
mailto:[email protected][email protected]</A>

[Brent Boshart]

Thanks for your responses. I'm not measuring elapsed time but want the real time.

Based on UTC time, I perform calculations for satellite positions and communicate with a telescope to track. The accurate (at least relative) time is critcial under high magnification. The whole thing is tricky timing as I communicate over a RS232 line with the scope. People are surprized about what I achieved with the Windows environment. Guess they need to now about PowerBasic!

Have a look at http://sattracker.hypermart.net/iss.gif for a sample of the tracking. (And yes, you will see that NASA uses software created with PowerBasic!!)

Thanks.

Brent

------------------


[This message has been edited by Brent Boshart (edited February 08, 2001).]

[Lance Edmonds]

Yes, TIMER is accurate to about 1/18th second. Counting execution time of code in Windows is a bit tricky to handle, but counting "real" time is not such a problem

The true amount of CPU time your app gets actually depends on the Quantum of the Operating System being used, and the number of tasks & processes running concurrently. The Quantum is the length of time allocated to a time-slice. For Win9x it is in the vicinity of 15-30mS, 60mS for NT workstation, and 120mS for NT server. The lomger the Quantum the more processing gets done before a context (task) switch occurs.

So, depending on the workload (tasks and processes), your app may get many time-slices back-to-back or it may get many interruptions.

In other words, TIMER will give you a rough idea of how long a task took to perform, but it does not tell you how much CPU time was used. Raising the priority of a given thread can help, but only for very short periods (ie, miliseconds).

To get a better idea of how much CPU time a thread used, GetThreadTimes() (NT only) can be used.

Much more accurate timers than TIMER are available, such using the multi-media timer or GetTickCount(). I understand the former can count in nanoseconds, and the latter is in milliseconds.

What is the nature of the duration you wish to measure?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

Brent--

Generally speaking Windows "time" values have a resolution of about one millisecond. Even the CoFileFileNow function, which is calibrated in 10-nanosecond increments, actually only "ticks" about 1000 times per second.

But it's very, very difficult to obtain guaranteed-accurate time readings on a Windows system. Consider the following PB/CC code:

WAITKEY$
sTimeNow = TIME$
PRINT sTimeNow

There is no guarantee that Windows won't "switch away" to another app -- end your app's time slice and start another app's -- in between those lines of code. Depending on the other apps that are running (how much they hog the CPU, etc.) several seconds could conceivably elapse between the time you ask Windows for the time, and the time your program uses it. So the time display may not accurately reflect the time that a key was pressed, and the time that appears on the screen may not actually be a "time now" by the time it appears.

My point is that the resolution of things like GetSystemTime is often a meaningless question. Even if it was accurate to the nanosecond, the fact that Windows performs task-switching in the way it does means that everything is a coin toss.

If you need truly accurate times there are thing you can do with your program's "priority" but it is not a recommended practice. It can interfere with the operation of other apps, and even Windows itself.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited February 08, 2001).]

[Brent Boshart]

I write an application where time resolution is very critical. I have always in the past used the TIMER function to the get fractional seconds which I believe has a resolution of about 1/18 of a second. What is the true resolution of the wmilliseconds parameter in the GetSystemTime call?

Brent Boshart http://sattracker.hypermart.net

------------------