Monitor cRIO CPU level

[RyanCahoon]

Originally Posted by wireties

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.

Just a question from the curious: does anyone know if the cRios has a vector/SIMD ISA?

[Greg McKaskle]

The PPC is an MPC5200, part of the 603e family. That means no altivec, no vector, just a workhorse industrial temp PPC with an FPU.

As for monitoring CPU utilization, I tend to peek at it after any major changes. CPU usage is not as important as correct operation, crashes, or bugs, but if you never look at it, you will almost certainly be surprised at how things creep in. I treat it like a thermometer. If you glance at it now and then you learn a bit more about how things contribute, and how you want to balance the system. And one of the implications of RT programming is that if it isn't well timed, it is wrong. In a batch system, it doesn't really matter when the results arrive. If you are controlling something, timing is far more important.

To put things into perspective, it is actually pretty easy to use up 100% of any processor, just write a loop with nothing to throttle it, and before you know it the CPU is racing full speed. This is usually fine, in fact it is what you want. The point where this isn't good is when there are tasks the CPU isn't getting to fast enough.

As an example, if you are processing images, processing DS packets, running control loops for motors and manipulator, and sending data back to the dashboard, you will probably find that it all works fast enough. BUT, if your control loops don't have enough oomph, or if your vision frame rate is too low, it may be time to look at performance and tune things up a bit. I'm going to talk about this from the LV perspective because that is what I know best, but the approach is generally the same for C/C++, but the tools and steps will be different.

The first thing I do is open up the System Monitor from Tools>>Real Time>>System Monitor. As with any monitor, there is overhead to measuring the CPU, and in order to get a better measurement, it is pretty important to click on the VIs tab and turn off the Track VI States option. Because there are so many VIs in WPILib, this will add lots of artificial overhead when monitoring, and all this will tell you is that three of four VIs are running in parallel, sort of like tasks. So you can look at this if curious, but you should generally turn it off. Now switch back to the Resources tab, turn on the Track CPU Usage option and Start.

At this point you may get a message about turning on the server. If you've used the FRC template, this should already be done for you, otherwise follow the directions to enable it, reboot the controller, then try again.

The upper trace for disk usage doesn't cost much, but won't be a concern unless you are storing LOTS of data on the disk/flash. The lower trace will take one second samples and show you the average usage. You can see the overhead before you run your program, you can see the usage of your disabled robot, your autonomous, your different teleop operations. As long as the operation is relatively similar for one or two seconds, you can get a feel for the expense of various tasks. I generally jot a handful of numbers in my notebook along with explanations and dates/times so later when things are different I can more easily refer to how they used to run.

As mentioned, 100% CPU usage isn't necessarily bad. If all of the tasks are being handled well enough, that is the important thing. What 100% means is that you probably can't add many more CPU intensive tasks without taking away from the current things.

Sooner or later you will want to speed stuff up, and the System monitor doesn't give enough info. I won't go into the tools for that because this post is already huge. I'll wait for someone to ask.

Greg McKaskle

[buchanan]

> I'll wait for someone to ask.

OK, I'll ask

We're interested in tracking CPU load because we'd like to apply any otherwise unoccupied CPU horsepower to sampling and smoothing noisy sensor inputs. It's easy enough to write a Thread (we're using Java) to do this as fast as it can, but we don't want to risk starving more important tasks.

It's a lot easier to tune things like this if there's an easy way to watch CPU loads during development. Any hints?

[Greg McKaskle]

If the noisy sensors can be made nonnoisy with better wiring or contacts, that is probably preferable. A second option is to use the averaging on the Analog object -- that way it is done by the FPGA and doesn't affect the CPU at all.

If you want something more fancy, you can do the conditioning when read and you probably don't need a thread running in parallel.

If you still use the thread, just make sure to add a delay to it so that it doesn't run hundreds of times faster than needed.

Greg McKaskle