LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the 55ms timer?

Solved!
Go to solution

I heard from someone that there may be issues resolving times less than 55ms in LabVIEW with Windows.  Can anyone give me more information on this?  Did this apply only to older versions of Windows like 95 and earlier or is it something that still affects LabVIEW on XP and 7 systems? 

 

If not, what resolution times can the modern operating systems provide?  

0 Kudos
Message 1 of 8
(3,968 Views)
This is a Windows OS issue. Actually the number is more like 18ms which is the highest resolution of the Windows system timer. I am not sure if they have changed anything in Windows 7 but I doubt it since Windows is not a real-time OS.


Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 8
(3,962 Views)

I see.  Is that 18ms timer actually dependable or, since it's not real-time, is that number subject to more error that usual when Windows is 'busy' ? 

 

0 Kudos
Message 3 of 8
(3,954 Views)

Why would say that it is not dependable.

 

I know I saw a couple of times where I had something heavy going on in my code that I actually saw the clock I called up from windows systray come to a standstill for several minutes.  Now that is actually a separate UI update process in windows that gets its data from the system clock, so theoretically, the clock could have been on time just fine and it was the windows clock application that was stalled.

Message 4 of 8
(3,936 Views)

The resolution has to do with timestamps. Meaning that if asked Windows what time it is (even if you're in Chicago), the accuracy would be actual time +/- error. In old version of Windows that error was 55 msec. With Windows NT that resolution was reduced to about 16 msec.

 

The issue isn't so much the resolution, as much as that you can't use an operating system like Windows to do real-time, or anything close to it, because the OS is preemptive. That means your process can be chugging along just fine, and wham! a Windows update comes in and you're completely hosed. 

Message 5 of 8
(3,932 Views)

Ravens Fan wrote:

Why would say that it is not dependable.

 


I meant "I would say that is not dependable."  I thought "I", my mind got my fingers typing "Why".

0 Kudos
Message 6 of 8
(3,915 Views)

Ravens Fan wrote:

Ravens Fan wrote:

Why would say that it is not dependable.

 


I meant "I would say that is not dependable."  I thought "I", my mind got my fingers typing "Why".


That was good for a chuckle!  Ravens Fan-your "Freudian Slip" is showing.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 8
(3,897 Views)
Solution
Accepted by davey31415

Here is a doc that give some of the timing resolutions for different Windows functions. It states the the precision for NT is Approximately 10 milliseconds for newer versions of NT(Approximately 55ms on Windows 95/98/ME, 15ms on Windows NT 3.1.)

 

Windows Timing Resolution

 

-Hunter

Message 8 of 8
(3,846 Views)