Can LabVIEW threads sleep in increments less than a millisecond?

[tarheel_hax0r]

The major problem with waits under Windows, especially NT based versions, is that the OS timeslice for an application is 20ms by default. What this means is that when your process (LabVIEW) is swapped out so another process can run (e.g. your e-mail gets mail, your mp3 player is decoding mp3s, the system clock ticks, the keyboard gets data), there is a minimum of 20ms before LabVIEW gets the processor back. This is an automatic delay of 20ms+ whenever it happens. As a result, delays of less than 20ms are not particularly accurate and are generally only useful for throttling CPU use.

You can change this 20ms to 1ms, but it will result in a lot more thread switching overhead for the OS. This is probably not much of a problem with a fast processor, but something to consider.

Three questions: Does "20ms" mean 20 milliseconds, or 20 microseconds?

Also, do you know what registry settings need to be changed in order to alter this time [down to 1ms]?

Finally, do you know whether the server versions [W2K server & 2003 server] are tuned a little better than the desktop versions [XP & the "Professionals"]?

Again, in this day and age [of 3GHz processors], it's really hard for me to believe that a context switch automatically [and necessarily] results in a 20 millisecond time penalty to the thread that does the relinquishing.

PS: I did a little googling, and I found an article from July of 2002 where a guy at IBM did some performance testing of the Windows -vs- Linux kernels, especially as regards context switching. He found that if you use system-specific calls [rather than generic, POSIX-ish calls], then Windows was about twice as fast as Linux [although I think he may have been using the 2.4 kernel, which has a different scheduler than the 2.6 kernel]:

RunTime: Context switching, Part 1
High-performance programming techniques on Linux and Windows
http://www-106.ibm.com/developerworks/linux/library/l-rt9/?t=gr,lnxw03=RTCS

RunTime: Context switching, Part 2
High-performance programming techniques on Linux and Windows
http://www-106.ibm.com/developerworks/linux/library/l-rt10/?t=gr,lnxw01=ConSwiP2

[DFGray]

20ms means 20 milliseconds (20 microseconds would be 20µs). I also did a bit of research and found out I was wrong. By default, background processes have a time slice of 10ms, foreground processes have a time slice of 30ms on WinXP Pro. You can change these using the performance options of the OS. I don't know exactly how to do it, but search your windows help for "time slice" or "performance options" and you should find it. It is buried pretty deep.

Server versions do have different time slice allocation, by default. However, the "quantum", the smallest possible time slice, is 3.333ms on XP (three quanta equals 10ms).

This all gets back to my original statement. Windows, is not a real-time operating system (well, one could argue CE is). Linux is not any better. If you really need one, use one designed for the task (LabVIEW RT, VxWorks, QNX, etc.).

[tarheel_hax0r]

I wrote a little VI that allows you to run empty For Loops that do nothing at all except sleep for prescribed intervals [and there's even an option to run the For Loop with no sleep whatsoever].

On a 2.8GHz Dell, running Windows XP & LabVIEW 7.0, 1000 iterations of both "1ms" sleeps and "2ms" sleeps gives an elapsed time of about 2 seconds, so it seems to me that on this box, the smallest increment of time is about 2ms, rather than 20ms.

The "0ms" sleeps do what I needed, however: On this box, you need to run the loop about 100,000 iterations before you get any noticeable elapsed time [of course, that could be a function of the granularity of the timer, but, at this point, I'm just happy to have found something that does what I need, so I'm not gonna worry about that].

If there's anyone from NI following this thread, it would be nice if we could get this "0ms" sleep trick into the official documentation, so that this "feature" doesn't get deprecated in the future.

[altenbach]

---

>
On a 2.8GHz Dell, running Windows XP & LabVIEW 7.0, 1000 iterations of both "1ms" sleeps and "2ms" sleeps gives an elapsed time of about 2 seconds, so it seems to me that on this box, the smallest increment of time is about 2ms, rather than 20ms.

---

I wonder what's wrong with your box. I see correct behavior for 1 and 2 ms.

Wait 1ms: elapsed time: 1.001..
Wait 2ms: elapsed time: 2.011..
(Very similar for wait next ms multiple).

This is under Windows 2000. 1GHz Pentium III. Same result under LabVIEW 7.0 and 7.1.

[tarheel_hax0r]

I wonder what's wrong with your box. I see correct behavior for 1 and 2 ms.

The obvious thing would be that it's one of the earlier Pentium IVs with hyper-threading, and perhaps the combination of LabVIEW 7.0 & Windows XP [SP1, not SP2] has some sort of a 1ms glitch w.r.t. the sleep times.

[DFGray]

I have seen the same sort of behavior (~2ms average sleep time with 1ms input) on my 2.4GHz HT Pentium 4 - it is probably a hyperthreading issue. However, I was curious, so I wrote a short VI to log the loop-by-loop behavior and plot it. The VI showed that the loop time oscillated between 1ms and 2ms, with most iterations at 2ms. Every once in awhile, something in the background would happen (e-mail arriving, disk flush, etc.) and the loop time would go to 6ms or more. I attached the VI (with a screenshot) below if you want to try it out.

[KellyH]

I submitted an issue report against the LV Help for this. If you encounter other situations where NI documents are missing information or have unclear or incorrect information, please submit that feedback directly so we can look into it.

Thanks!
Kelly Holmes
LV Documentation

[altenbach]

Kelly, this thread drifted a bit from originally (1) looking for sub-ms wait, to (2) the discussion on forcing a task switch using a 0ms wait, to (3) issues with the minimum waits on hyperthreaded CPUs.

It is not clear what part you submitted for the help team ... 😉

I think (2) should be mentioned on the help pages for the wait functions.

However, the truth is a bit more complicated. For example, if you would modify my demo VI for higher loop counts (e.g. 10000), you'll notice that the entire concept of 0ms wait (to cause a task switch) falls apart after a few thousand iteration and the array elements no longer alternate. So, in reality, the issues are probably more complex.

[Robert M]

The issue with 1 ms vs 2 ms on both the "Wait" and "Wait Until Next ms Multiple" functions ties back into how they are implemented in Windows. The way they are set up, the Windows scheduler only provides a 2 ms resolution. The issue only occurs on centain processors, however, and it seems that newer processors are more likely to exhibit the behavior. Most Pentium 4 machines show these results while most Pentium 3 machines do not.

The new timed loops in LabVIEW 7.1 are implemented differently, and do gurantee 1 ms resolution, so using them is the best workaround if you need the 1 ms resolution.

Robert Mortensen
Applications Engineer
National Instruments

[KellyH]

---

@altenbach wrote:
Kelly, this thread drifted a bit from originally (1) looking for sub-ms wait, to (2) the discussion on forcing a task switch using a 0ms wait, to (3) issues with the minimum waits on hyperthreaded CPUs.

It is not clear what part you submitted for the help team ... 😉

I think (2) should be mentioned on the help pages for the wait functions.

However, the truth is a bit more complicated. For example, if you would modify my demo VI for higher loop counts (e.g. 10000), you'll notice that the entire concept of 0ms wait (to cause a task switch) falls apart after a few thousand iteration and the array elements no longer alternate. So, in reality, the issues are probably more complex.

---

Sorry, I should have been more clear. I submitted the feedback on the wait function documentation. I'll add these additional comments to the issue report.