RT null thread Execution during time critical tasks

[awsrasool]

Hi, I am trying to implement a simple parallel genetic algorithm on a quad core RT-desktop computer, and I have been using the real-time execution trace toolkit  to see how the processor allocation is handled.  I am attaching a sample VI that runs 4 identical time critical subVIs each one running on a dedicated processor, my problem is that when I view the execution behavior using the trace toolkit, each of my tasks is being interrupted by the "ETS Null Thread", even though the tasks are not waiting for any objects or memory access.  Also the interruption by the ETS null thread is not periodic in any way, I have tested the execution of the VI and each time I get a different execution graph from the toolkit, some runs the tasks do not get interrupted at all until they finish execution, and some runs are filled with task interruption.  I am attaching the project file that I am currently working with along with a couple of log files obtained from the execution trace toolkit.

Can you please let me know if I am missing something here, whether I need to disable any type of extra services that the cores are doing, or the problem is with my implementation, or if this is actually expected behavior. 

Thank you,

[awsrasool]

Just to clarify, the attached project file contains a VI that calls 4 time critical tasks.  each of the time critical tasks runs 2 for loops, the first generates 93 random numbers, and the other loop is responsible for repeating the random number generation process 5 times.  the 4 time critical tasks do not share any variables, semaphores, or memory between each other.

[Peñata]

Hi awsrasool,

The ETS Null Thread is an idle execution thread (see the LabVIEW Real-Time Execution Trace Toolkit Help, section Viewing Trace Sessions»Viewing and Analyzing Thread Events for more information). This thread is used whenever activity on a specific core has gone idle. This thread is not interrupting your time critical threads, it is simply going to this thread when your time critical loop is going idle.

Thank you for choosing National Instruments.

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support

[awsrasool]

Hi Aaron,

Thanks for the reply.  That's what I thought the problem was at first, but then I was able to determine that the time critical tasks are not going idle at any point during their execution.  The figures I am obtaining from the trace execution toolkit show random interruption of the time critical tasks throughout their execution cycle.  Also,  the flags in the trace execution toolkit are not indicating in anyway that the tasks are waiting for any objects.

But assuming that my tasks are going idle, since all am doing in them is generate 93 random numbers, is there a better way of doing that so that the tasks wouldn't go idle at any time?

Again thank you very much for your reply,

Aws 

[Peñata]

Hi awsrasool,

One thing you could try is to just have a while loop (and maybe some trivial code like and addition) in your SubVIs as opposed to generating random numbers in nested For Loops. Another thing you could try is to set up 4 timed loops instead of 4 SubVIs and assign each loop to a specific processor. Then you could also have another 4 timed loops (also assigned to specific processors) at a lower priority that is doing something time intensive so that when there is idle time in your higher priority timed loop, it should jump to the lower priority loop for that specific core instead of the ETS Null Thread.

Thank you for choosing National Instruments.

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support