Consider the following application, where there are two primary loops dividing the application into a time critical task (Control and I/O) and a non-deterministic task (Monitoring, Simulation, and Network Communication). Assume the application is running on a dual-core PXI Real-Time controller—so there are two available processor cores for these tasks to run on.
Figure 3 - Example LabVIEW Real-Time control application
Both of the Timed Loops are processing intensive, so the operating system will auto-load balance the tasks across the two available cores. In addition, there is networking overhead that must be scheduled (i.e. the processing required by the shared variables to pass data over the network). By examining a trace in the Execution Trace Toolkit 2.0, we can observe that even though the CONTROL task is time-critical, it is sharing CPU 0 with the shared variable processing (denoted by NILXTCORE, or NI Logos XT). The MONITORING task, which is dimmed in this view, is using up the other CPU.
Figure 4 - Example Trace of the application, with the CONTROL task sharing a CPU with network communication
Note how the Real-Time Execution Trace Toolkit allows for simultaneous viewing of threads running on different CPUs, this capability is ideal for debugging parallel applications.
If desired, the Timed Loop parameters could be modified to dedicate the CONTROL task to it's own CPU. This is accomplished by changing the Automatic processor assignment to Manual, and then choosing which particular CPU to assign the task to.
Figure 5 - Assigning CONTROL task to CPU 1 using Processor Affinity
Now, a second trace session can be viewed to see what this change in behavior did to our application. In this scenario, the CONTROL task is dedicated to it's own CPU, and the ETS Null Thread is shown, which signifies that the operating system is not scheduling anything else during the span denoted in blue. In other words, the CONTROL task has CPU headroom to allow for enhancements to the application such as tighter control loops or the addition of more in-line processing.
Also note the dimmed section of this trace, which shows that now MONITORING task and networking tasks are sharing the other processor, which is the desired behavior.
Figure 6 - Example Trace of the application, with the CONTROL task dedicate to it's own CPU