Monitor cRIO CPU level

[keehun]

Is there any way of monitoring the CPU usage? I wouldn't mind any methodology as long as I could read it while driving it.

Just out of curiosity I guess, and planning how much processing "room" I have left or if I need to start optimizing something. It would hate to have developed really quality things by week 5 but then run out of "processing room" and rush to get that in the clock cycle and everything else gets screwed up.

[keen101]

are you really worried about it? It's a huge upgrade from the previous microcontrollers. I mean come on, the cRIO is a (300Mhz?) Power PC based computer! Heck it could run embedded Linux! I actually think it runs vxworks on UNIX.

In my opinion you shouldn't really have to worry about it. It's practically a computer.

But, even though it's probably not needed at all, it would still be cool.

[keehun]

Originally Posted by keen101

It runs vxworks on UNIX.

Yeah, before the season I was joking how we should run OSX on this thing. ;-)

Originally Posted by keen101

In my opinion you shouldn't really have to worry about it. It's practically a computer. But, even though it's probably not needed at all, it would still be cool.

Perhaps it's not needed. But I definitely want it for the cool-factor. But seriously I just want to watch it for any spikes, repeated patterns, etc. Who knows if that while loop is just killing the CPU

[synth3tk]

Just to reinforce what keen stated, the old controllers were significantly "weaker" than the cRIOs.

As far as I know, people didn't have issues with processing limits on the old IFIs, so I don't think these will be much of a problem.

[nathanww]

The quick way(and the only way I can think off off the top of my head) is to create a thread that basically just monitors how many times it can loop in a given mount of time. Less should mean more CPU load

[wireties]

It runs vxWorks and VxWorks is an industrial real-time operating system. It does not run "VxWorks on Unix". VxWorks has a task-based profiler called 'spy'. I have not checked to see if FIRST/NI/WPI included it in the kernel image they gave us. If this feature is in the kernel you can see the spy output from the command line or from Workbench.

HTH

[Greg McKaskle]

spy and similar serial terminal tools will give you a performance dump.

If using LV, it is pretty easy to open the Tools>>RealTime>>Real Time System Monitor. Unfortunately, its default settings have lots of overhead, so hit the other tab and turn of VI state. On the original tab, turn on performance, either leave disk on or off, doesn't matter much. Now hit the start button and observe the chart.

Greg McKaskle

[Tom Line]

Thank you! We were looking at doing some additional and rather extensive image processing, and I wasn't sure how the CPU would hold up.

It there a threshold of CPU usage we should strive to stay below?

[Alan Anderson]

Originally Posted by Tom Line

It there a threshold of CPU usage we should strive to stay below?

Don't go over 100%.

Seriously, unused CPU cycles are of no value. There's no benefit to limiting yourself to only a fraction of the available processing power.

[AustinSchuh]

Originally Posted by Alan Anderson

Don't go over 100%.

Seriously, unused CPU cycles are of no value. There's no benefit to limiting yourself to only a fraction of the available processing power.

I'm not sure how good the vxWorks scheduler is, but wouldn't you want to leave a couple of percent left so that the processes that need to be responsive, like the one that talks to the DS, can be scheduled easier and on time?

[Mike Soukup]

Originally Posted by AustinSchuh

I'm not sure how good the vxWorks scheduler is, but wouldn't you want to leave a couple of percent left so that the processes that need to be responsive, like the one that talks to the DS, can be scheduled easier and on time?

VxWorks has an excellent scheduler. If the controller was designed properly (and I assume it was, I just haven't looked at the relative priorities of the tasks) the critical tasks that we rely on will all have appropriate priorities. VxWorks guarantees that if a higher priority task wants to run, it will run before a lower priority task.

[Uberbots]

Originally Posted by keen101

are you really worried about it? It's a huge upgrade from the previous microcontrollers. I mean come on, the cRIO is a (300Mhz?) Power PC based computer! Heck it could run embedded Linux! I actually think it runs vxworks on UNIX.

In my opinion you shouldn't really have to worry about it. It's practically a computer.

But, even though it's probably not needed at all, it would still be cool.

its 400Mhz

but that also means we can throw much more complex tasks (image processing, array crunching, super-linear-time operations over big data sets) to choke the processor with.

[Kingofl337]

I think it's very important to know the available processing power. Currently vision in Windriver is being done at 10FPS if we have more available processing power when the robot is programmed, we could increase the FPS rate for more fluid tracking. The fact the cRio is 400MHz is moot because it's doing alot more work already then the old system. It's running an OS, it's running a network stack, communications protocol, and doing vision.

[Tanner]

Lab View has a option to monitor the CPU usage and memory usage on the cRIO.

Tools -> Real-Time Module -> System Manager

You can do it, but there's really not much of a reason to do it as stated by others.

-Tanner

[wireties]

"The fact the cRio is 400MHz is moot" - Well, its not exactly moot. The cRIO is doing a lot more work but it is many many times faster. Its a 32 bit machine with primary and secondary caches running at 400Mhz with a floating point co-processor. It could be nearly 200X faster under some circumstances, more if you need floating point.

Running VxWorks is not like running windoze, its an industrial real-time operating system. The network stack is an extra load but the old processor was still handling application level comms with the driver station. And the work done by the network stack in VxWorks can be prioritized relative to any other activity (but interrupts).

The vision work is this game is a pretty simple algorithm. I don't think it will begin to stress the cpu bandwidth of the cRIO.