RT Linux CPU load makes UI laggy

[Bas.v.E]

Hey guys,

At this moment we are doing a project on a  NI PXIe-1092 chassis with a  NI PXIe-8880 controller.  The controller is running linux RT. 

The plan of the project is to use the controller to control and measure but also as a UI.  We can connect a mouse and keyboard via USB and the controller has video output capabilities. 

Currently we are measuring signals on a few IO cards and we are displaying this data on the UI. 

We see that the UI update rate is extremely laggy and slow.  Especially the UI panels that have graphs on them. 

We have seen that the 'anit-aliasing' option on the graphs,   has a large effect on the UI updates. We have disabled this option for now and then the UI updates are smooth again but the details on the UI are not that nice. 

We are also seeing a fair bit of UI lag when doing file access, and we think this is due to CPU priorities.

Is there another way to solve this? Is there a way to give more priorty to the UI updates on RT linux? We have plenty of CPU load available. 

[Bob_Schor]

You are running Linux RT (which stands for "Real-Time"), an operating system designed to not run a User Interface (which needs to be designed to be responsive to users. 

Windows 10 is an example of an OS that sacrifices "Real-Time" for a multi-tasking OS with many "threads" that permit a responsive User Interface.  You would probably be better served to purchase a PC Laptop running Windows, install LabVIEW on the Laptop with the Real-Time Module so that it can connect with the PXIe system using Ethernet, and developing a LabVIEW-RT Project with the Real-Time (deterministic, fast hardware-clock-driven I/O) tasks handled by the PXI and its powerful PXIe controller, with all of the UI taking place in the Host PC, allowing the two different OS's to do what they each do best.

Bob Schor

[rolfk]

Another thing to watch out: you say you have enough CPU power, which may be true or not. If it is and your UI seems laggy you may be using routines in your processing loop that somehow are forced to run in the UI thread. This may be for good reason as the routine needs to be protected from multithreading access for some reason, or it may simply be an oversight for whatever reason.

Things to check:

- VI Execution system assignment, generally without any specifically and well argumented reason all subVIs should be set to run in the caller execution system and the top level VIs should be set to run in one of the non-UI execution systems.

- Call Library Nodes set to run in the UI thread: There can be very valid reason to do so and unless you know for a fact that the underlying shared library function is multithreading safe, it is the only safe setting. But it forces the function to execute in the UI thread, which will of course interfere with any user interface updates, especially if the function has a long execution time. Once LabVIEW passes control to that function, the UI thread is totally blocked until the function returns and in that time LabVIEW can not do UI updates!

Ultimately, RT systems are tuned specifically to give higher priority to the different non-UI threads to help guarantee the RT characteristics and the UI thread has simply a lower priority especially since on a typical RT system there simply is no UI at all!!

Your use of the RT system sounds almost as an abuse, since you apparently don't care very much about RT characteristics but about nice UI responsiveness. But even then, in almost all cases I have come across such situations, it is due to badly configured VIs and/or Call Library Nodes.