11-30-2015 01:36 PM
Target hardware: cRIO-9068
LabVIEW Full Development System 2014
I'm puzzled by the information provided by the "RT Get CPU Loads.vi". I wrote a simple test program which I run in interactive mode on my RT target to demonstrate the problem. See the screen shots in the attached PDF.
Figure 1 shows a timed loop that executes every 500 msec, changing the state of a boolean indicator and updating the "CPU loads" front panel indicator. Figure 2 shows the front panel. Observe that the "Total (%)" field consistently indicates about 17%. Why is this number so high when the program is doing almost nothing? Figures 3 and 4 show similar results for a while loop with a Wait vi.
My actual applications, which are considerably more complex than these test programs, are consistently indicating CPU loads of 100%. This is worrisome, but I'm not sure I believe it given the findings of my test program. Can anyone shed some light on these results?
TIA
Hugh
Solved! Go to Solution.
11-30-2015 02:15 PM
This is mostly a guess, but I'd say putting the "Thing doing the measuring" inside the "Thing being measured" has a lot to do with this.
Try removing the Get CPU Load function from inside the Timed Loop. Put it in an "ordinary" loop of its own, with (maybe) a 5 second Wait Function (which pretty much takes its time out of the picture). Your Idle time should go way up (I'd guess >99%). Let us know the results ...
Bob Schor
11-30-2015 02:30 PM
Bob,
I just tried what you suggest and note a modest reduction in CPU load - now about 15% - but not the dramatic reduction you were expecting.
My only other theory is that the process of updating the display on my development computer is loading the RT CPU. However, in my actual system which I don't run in this interactive mode but monitor via health and status packets transmitted over the network, I'm seeing similar results, as I mentioned previously.
Hugh
12-01-2015 12:56 PM
It took me a while (I'd accidentally unplugged the switch that connects my PC to my PXI -- just found it by tracing the Ethernet wire and "Oh, I forgot about that switch ... Who turned off the power to it? Oh, yes, I remember doing that last week, I forgot the switch was plugged in ...".
My PXI controller is an 8108, which has a dual core Pentium of some kind in it. Accordingly, I get two CPU Load reports, one for each core. It's pretty clear that the Timed Loop is running in Core 1 (as the time goes up as I increase the computing inside the loop).
As shown here, the Timed Loop runs for three cycles at 0.5 Hz, trying to compute a million random numbers (seems to take a fraction of a second, maybe 50-100 msec). At half-second intervals, I get the CPU Loads in a separate loop. To ensure that at least one of the measurements gets a full cycle of the Timed loop, I delay the Timed Loop start by 1/4 second.
Here's what I get on the fourth measurement (the second through fourth are similar).
You will notice that Core 1, which has the Timed Loop, is busy 13% of the time, while the other loop is only 0.3% busy. Looking over all 6 readings, Core 0 never goes above 0.6%, while Core 1 is either <1% or around 13% (recall that it might not be started, or may be done).
I ran this once more, reducing the number of random numbers by a factor of 100 (to 10,000). The first Loads were 0.5% and 0.75% (initialization), the next was 1.6% and 3.4% (Timed Loop starting), and the last four (when the Timed Loop was running) both Cores were 0.3% or lower. So, in my hands, once the Timed Loop is running, I can "measure" its Core Load with minimal impact.
Bob Schor
12-09-2015 03:59 PM
A few final comments and some resolution.
The cRIO-9068 contains a 667 MHz Dual-Core ARM CPU. When I display the CPU usage for both CPUs I see that one is loaded at about 15% and the other at 1%. If I run the Linux command line utility "top", I see CPU 90% idle, which seems to correspond to the average of the two CPU loads shown:
((100% - 15%) + (100% - 1%)) / 2 = 92% -> pretty close to 90%
When my test application is not running, top indicates 91% idle. So most of the CPU usage in this case is due to the operating system. The additional load from my application in this instance is almost unmeasurable. My results are consistent with Bob Schor's taking into account the fact that he ran his experiments on a somewhat faster Pentium. I am no longer confused!