LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

timed loop occasionally slow in executable

I have an application that consists of several timed loops, each running some sort of a display / control page for a variety of sensors.  Everything seems fine in the development environment, but when I build an executable I experience occasional periodic slow downs.  I can't seem to tie them to anything apart from that they occur more often when the user is interfacing with the machine (they still occur when the user is not present, it just seems to be less frequent).
The only relevent thing I can think of is that the slow downs happen on core duo machines (it happens on all the ones I've tried), and the development environment is on an older machine before the core duos. 
Is their some setting, patch, workaround to prevent this slow down?
0 Kudos
Message 1 of 5
(3,404 Views)
Off hand, I do not know of any reason that your application should run slower when built into an EXE. This is not a documented issue/bug, so there isn't a simple patch that you can install to resolve the problem. You may want to try replacing your timed loops with while loops (using a time delay inside) and see if that seems to fix the problem. I assume that you are developing on LabVIEW and not LabVIEW Real Time because you mention building an EXE (not deploying the application to an RT target).
 
It would also help if you continued to look out for any factors that may be correlated with the slow-down. Trying out your code on additional core-duo machines and measuring the exact loop rate achieved would help you gather some concrete data so that we could do additional troubleshooting at National Instruments and zero in on the problem.
 
I hope this helps!
 
Casey Weltzin
Applications Engineer
National Instruments
0 Kudos
Message 2 of 5
(3,386 Views)
About one year ago I encountered problems with timed loop. According to NI's investigation, this is related to hyperthreading. See above extract from three answers from NI (JR Andrews, Biren Shah and Aljosa Vrancic) :
  1. The preliminary investigation of the issue indicated that it may be due to hyperthreading (or having dual processors) and that disabling hyperthreading resolved the issue as a potential workaround. If you have the time and ability, I would be interested to know if you were seeing the issue on a hyperthreaded machine and if disabling hyperthreading does in fact resolve the issue for you. I can then pass that information on to the developer to assist them in fixing the issue.
  2. Even though your computers only have 1 processor, that processor may be using "Hyperthreading" to make it appear to the OS that there are 2 processors. You can check this by looking that Performance tab in the Windows Task manager or at the number of processors shown in the Device Manager. Disabling the LV option for "Run with Multiple Thread" would probably not have any effect because to Timed Loops are always their own thread and that setting only applies to non-timed loop LabVIEW code. So I wanted to clarify that double check that your machine indeed does not have hyperthreading. To disable hyperthreading, you can go into the BIOS and you should be able to disable it.
  3. It looks like a problem in SetThreadPriority() OS call that hangs for some reason.  The problem seems to happen only if the requested priority is equal to the current thread priority so the work around is to check thread priority and do not make the call if it is set to the correct value.  I run the test overnight without any problems.

I was told that this unexpected behaviour will not appear on dual core machine so my answer may not solve your problem. I replaced the timed loops by while loops and the application runs now flawlessly.

This link on an internal site may help NI.
Because the link is on an internal site, only NI is able to open it.
0 Kudos
Message 3 of 5
(3,361 Views)

Thanks guys.  A few things I have since discovered.  First, scratch the problem with only executables.  I installed the development version on one of our core duo machines, and saw the same slowing behavior.  Since we need to deploy on core duo, I changed the timed loops to while loops, and it runs ok now.  Most of the time the execute at their set rate - between 50ms - 250ms.  A slow down can happen at any time, even if I haven't touched the machine for minutes. 

JB - you mention changing priorities.  Most loops have a variable priority depending on the state of the front panel vi in the timed loop (50 if closed, 190 if open, 210 if open & in front).  The number is always sent to the "priority" input on the right side.  Most of the time the priority doesn't change, and even if it does, only one does at a time (assuming the user only does one window action - open, close, pull a different one to the front -  per 250ms).  If I read you right, you are saying that I sould only wire this when it is to change, which I assume means wire a "-1" when it is not to change?  If that is what you are saying, I'll have to give it a try.

Also is their anyway to turn off hyperthreading - or remove the duoness of the core duo?  I didn't see anything obvious (but I often miss stuff like that).

0 Kudos
Message 4 of 5
(3,346 Views)
JB - you mention changing priorities...  ...If I read you right, you are saying that I sould only wire this when it is to change, which I assume means wire a "-1" when it is not to change?  If that is what you are saying, I'll have to give it a try.

No ! This is in the source code of LV itself and therefore you have no way to influence it, unless you are one of NI's developer !

To disable hyperthreading, you can go into the BIOS and you should be able to disable it.


A last copy of an email that I received exactly one year ago (06/06/06):

We have made some progress in making this behavior more difficult to reproduce, but we are still trying to trace the origin of the error. For dual-processor machines, this will not be a problem. It seems fairly certainly specific to hyperthreading machines.

We will keep you in the loop as progress is made
0 Kudos
Message 5 of 5
(3,325 Views)