LabVIEW
Difference Between Getting CPU from System Resource vs. RT Get CPU
To test your theory you could run your test VI while running and not running in the background a time consuming task (such as a shell script) that runs outside of the LabVIEW runtime engine, but is started by your test VI.
Hello guys. I know I am late to the party but I see a big difference when comparing CPU load from RT GET CPU vs the System Resources approach. Here is my CPU Load evaluation code:
I am running this on a cRIO 9053 that has two CPU's. Lets call them CPU 0 and 1. There is also a Timed loop in my code that is either "busy" or "not busy". The Timed loop is told to run on CPU 1.
There is almost a 50% difference in CPU load between the two approaches! Which one can be trusted? I want to know the actual, total, CPU load in percentage.
When the Timed Loop is "busy", the difference on CPU 1 is almost 50%:
Then the timed loop is doing "nothing" there is no visible differences:
UPDATE ON MY POST ABOVE:
I am honestly not sure what is going. I am getting different results now. Not quite sure what I did beside changing some UDP code inside the timed loop. I suspect the references weren't getting closed properly. For whatever it's worth I am still getting different results while getting CPU load from System Resources vs RT GET CPU:
NI MAX is providing me with the same results as from the SystemResources case. So maybe thats the one to trust?
Max uses the NI System Control API too to query remote targets. So it's not surprising that it gives you the same values as when directly calling those functions. RT Get CPU is a remainder from the old Pharlap and VxWorks cRIO devices. Those devices were single core CPUs and the API had originally no provisions for multi core architectures.
It calls a custom shared libary ni_emb.so, which was also present on those old controllers and the only public way to query those low level information. What that shared library exactly does on a Linux OS is not documented, but there are a myriad of file entries, system calls and what else to retrieve various information such as CPU usage and they in themselves are not always easy to match with each other as they tend to use various methods to measure these things.
Generally, the absolute value of these variables is anyhow more a guesswork than exact science. They are good to see a trend and estimate if the system is close to getting overloaded but anything else is usually interpreting things into it that are not fully true.
