The new NI Linux Real-Time uses a real-time scheduler similar to the one on current real-time targets to handle the time-critical code scheduling and a completely fair scheduler (CFS) to handle all noncritical code scheduling. Current real-time targets with dedicated RTOSs rely solely on a real-time scheduler to manage both time-critical tasks as well as lower priority system tasks. The CFS in NI Linux Real-Time offers improved performance as lower priority tasks are more efficiently scheduled. To learn more about CFS, visit Inside the Linux 2.6 Completely Fair Scheduler.
Beyond the change in scheduler, you should also be aware of differences in multicore support on NI Linux Real-Time as all NI embedded hardware devices which support this new RTOS are multicore. With respect to multicore support, it’s especially important to follow programming best practices and avoid running a time critical loop on a processor core at 100 percent core utilization. This is because each core in multicore NI Linux Real-Time systems needs some amount of time for OS maintenance/overhead functions, without which system performance can be severely affected. To avoid this performance degradation, ensure that time critical loops allow for the CPU to sleep on the order of 10 milliseconds per 10 seconds of operation to allow for overhead processing.
It’s also important to note that performance degradation can occur in both time critical and system tasks on multicore systems running NI Linux Real-Time if serially dependent tasks are allowed to run in parallel across processor cores. This is because of the inefficiency introduced in communicating information between the serially dependent tasks running simultaneously on different processor cores. To avoid any such performance degradation, follow the LabVIEW Real-Time programming best practice of segregating time-critical code and system tasks to different processor cores. You can accomplish this by setting a processor core to only handle time-critical functions, and specify the processor core to be used by any Timed Loop or Timed Sequence structure as illustrated in Figure 4. You can learn more about the best practices in LabVIEW Real-Time for optimizing on multicore systems at Configuring Settings of a Timed Structure.
Figure 4. There are two methods to assigning processor affinity using the Timed Loop structure in LabVIEW Real-Time: (1) set the processor either by double-clicking on the Timed Loop structure to bring up the configuration dialog or (2) wire a value directly to the node on the left of the structure.
As is recommended with all system upgrades, you should re-validate your application after migrating to an NI Linux Real-Time based target as there may be improvements or degradations in the performance of individual functions which may affect your application's ability to meet all system requirements. In particular, memory allocations on Linux based real-time targets can have a greater impact on jitter.