> >According to National instruments, the 55ms timer resolution applies to
> >Windows 3.x. Here is an excerpt from the Knowledge Base document #
> >1CAEE34V on NI's web site:
> >
> >
> >LabVIEW or LabWindows/CVI timer functions use the operating system
> >timers. The time resolution of these timers depends on the operating
> >system. A list of typical timing resolutions on different operating
> >system is given below. This means that any software timed operation
> >would be accuracy of +/- 1ms on a Win95/NT operating system.
> >
> >Windows 3.x = 55ms, Windows 95/NT = 1ms, Macintosh 68k = 17ms, PowerMac
> >= 1ms, SUN Solaris= 1ms
> >
> >*************************************
> >
> >I do not know whether this "system timer" is the "stop watch" timer or
> >the timer upon which the time and date is based, or if NI has no idea
> >what it is talking about. Some clarification is in order on this
> >subject. I will agree with Helmut, however, that any application that
> >relies on the milliseconds to record or control events (other than loop
> >timing to conserve processor time)is ill advised.
> >
The resolution being discussed here is the stop watch. Again, it is a
relative timer with a unit of milliseconds that overflows about every 30
days and is relative to the last time the computer was rebooted. The
Date and Time function doesn't overflow until about 2040, and has a unit
of seconds. Most platforms do not provide the system time with any
fractional time. Win32 does and its resolution is the old standby from
the DOS days of 55ms or 18 ticks per second. So at least in this
situation, NI is correct, though the article could have been more
specific as to which timer it was referring.
> A quick test (Win98, LV5.1, P233) using a loop to build a numeric
> array with both the LV internal Time and Date function and the
> kernel32 GetSystemTime call returns double precision numbers that
> remain "stuck" for 50 or 60 mS (i.e. 55mS) and then update to the new
> value. The 3rd digit of precision remains at zero. This indicates
> that the extract above about 1mS accuracy doesn't apply to the
> Time/Date function and Greg's comment is dead right. For platform
> independence the LV internal function may be preferred.
>
> The advantage of the kernel32 calls is they can provide UTC with the
> ability to SetSystemTime (similar syntax to Get except return value
> wired for error as numeric 32 bit integer). Good for external
> references like SNTP servers or GPS units.
>
> You are not stuck with only UTC as the GetLocalTime and SetLocalTime
> kernel32 functions have the same syntax but work in the local time
> zone. Please note that the technique for wiring with clusters and
> adapt to type is only recent (LV5+?) - earlier versions may need
> separate dlls to get at the kernel32 call as it uses pointers to
> structures (don't ask me about the details!).
>
Thanks for the confirmation. I really like seeing people put together
elegant tests to actually measure the timing/accuracy rather than basing
important decisions on guesses and the like. It also keeps people like
me honest since I'm typically going on memory.
Greg McKaskle
