RT System Configuration tools are excessively slow

[QFang]

Hi everyone!

We currently make heavy use of calls to the legacy RT utilities for getting the CPU usage and the RAM usage for self-monitoring.

Since these VI's have been obsoleted in 2012 and 2013, we finally took some time to investigate how to get the same or better functionality out of the new tools, which in theory should be better.

What we found was that the legacy calls execute 200 times (CPU) to 600 times (RAM usage) faster than the new calls.  Essentially we go from sub ms per call to 6+ms per call using the new tools.

Either we are horribly missusing these calls, or the VXWorks target really doesn't like the way the new functions work in the background.

We ONLY have VXWorks targets here, so we have been unable to check if this is an RTOS issue or if the performance really is this bad across the board...

I attached the VI in 2013. Before you can open it, you would need to add it to the scope of an RT target in a project.  This VI should take but a few seconds to run in development mode (target dependent) and we would truly appreciate comments on performance on any target, both VXWorks and PharLAP and NI's RT-Linux.

PS: I also added a 2011 version, but I'm not sure if that worked out right.

PPS: I made a snippet in 2013, sorry for the mess, but this was just a quick and dirty look at averaged call times..

[QFang]

Just added a 2011 project with the VI already added to a target to make it even simpler to run this benchmark..

[Zach-H]

I don't believe you're using the System Configuration API incorrectly, but there certainly appears to be a performance difference between the two methods for grabbing the information. Both accomplish their goal of providing long term system health information, but the API certainly works differently than the RT Utilities VI's. As the performance difference is so different I'll be filing a correct action report to R&D so that it can be investigated. I'll update this thread with the number once its filed.  

If you're looking for low level execution and memory information the Real-Time Execution Trace Toolkit may be the correct software for your uses. 

We appreciate you reporting your findings!

-Zach

[QFang]

Thanks for listening and looking!  The execution trace toolkit (which we have) is more of a development tool, not for self-health deployed checks.   For now we will keep using the legacy calls, but if and when they break, our use can continue by wrapping the new API in a FG that buffers the stat's of interest and only does a new call to update the values if a "last called" timer has overflowed. This way we can happily fire the "give me stats" calls asynchronously the way we are, without taking too much of a performance hit.. of course, the values reported will be the same if calls are made to close together, but thats acceptable compared to the CPU cost.

BTW the speedy but low overhead legacy calls have allowed us some impressive fidelity into memory allocations for periods of months.. something I dare you to try with the execution trace toolkit.. last I tried that on this project (when we had an active memory leak) it crashed (or made controller unresponsive) within ~10 minutes which was too short of a time to show a leak or not, as the dynamic allcoations would overshadow the "bytes at a time" leak..  In fact it would take about 2 days to show the leak trend beyond a doubt in that case... those where long days.. anyway, like I said, thanks for your time and for listening!!

[Zach-H]

Sorry, I forgot to update the thread. The CAR number is 428512. I'd recommend checking the bug fix list of future versions to see if its been fixed. 

All the Best, 

Zach

[QFang]

Thank you Zach, I appreciate it and hope that I will be able to continue using the RT Utilitiy calls for the forseeable future.

-Q

[QFang]

As NI continues to evolve, we are now very close to a point in time where it is conceivable that the obsoleted 2011 functions will no longer work, yet the status of this issue seems to have not really changed.

I implore NI to either re-add efficient calls for cpu and memory usage OR bring the Sysconfig api to the same level of performance (which I don't think is possible as it seems the sysconfig api was designed for radically different use cases).

As our products continue to evolve, and we push the limits of what is possible on our hardware platforms, we find it useful to make our software self-aware of memory and cpu usage, such as "don't start this process unless CPU usage is less than 70%", while other modules will grab the numbers to determine if we are leaking memory or if memory is critically low, etc., but the point is, depending on the modules active at any point, we could be calling these functions at lot, in different threads, and the sysconfig API simply does not support such heavy use.