RT performance profiling tools

[VIGuy]

I know about the RDTSC register and I know about the "Profile VIs" tool.

What else is there that could tell me things like how much the proccessor is actually being used (like NT task manager, or "top")?

If you gents have any other suggestions or tips, I'd like to hear them.

[Ben]

Hi VI Guy,

I do not think there anything quite like that in LV-RT.

In RT the approach is slightly different. There are some pretty cool tools (do remembr where, not on RT machine now) that let you bench mark the times of the various loops. Specifically the time critical loop.

I'll see if I can roust them up tomorow AM if I hvae a chance.

Ben

[Ben]

OK, I did not get back to you yesterday as i had intended and my search this AM came up empty. What I was looking for was a set of VI that we used in the LV-RT class that gave you access to the hardware clock to get usec resolution on timing operations in LV-RT. NI RT support should be able to point you at a link.

When people ask questions like this, it is generally due to one of two reasons, just curious, or have a problem.

Which are you?

We get alot of non-RT related questions on this list so I have to ask, are you familiar with the concept of RT regarding determinism, time-critical functions etc?

Please take no offense, I just want to phrase my responses appropriately.

Trying to help,

Ben

[VIGuy]

I believe you are thinking of the RDTSC register. And yes I am familiar with it.

Right now we have a system that is working and the determinism is right on, but the communications are "jerky". This makes it appear that it is at the limit of its 866 MHz processor (which is hard to believe). We want to add more features to it, but we want to know where our code inefficiencies are, if any and how much processor we have left to include some real time data analysis, or to scale up the number of channels it is currently controlling.

This is a first generation product we are working on, and we are still learning alot about it.

If we could see how much time each thread was spending being executed we would be able to zero in on problem areas. Becau
se its an RT system, we have each sub system running in its own thread (2 comm threads, DAQ thread, and the control thread).

We could drop RDTSC peeks at a zillion places in the code and analyze all the data and figure out where the problem spots are, what thread spends what time sleeping and executing, etc. Or, optimally, we just ask the RT task scheduler what it works on the most.

Does the Phar Lap ETS offer any additional tools that would assist in this matter?

[Ben]

None that I know of.

We have built timers into our apps that get transfered via UDP (using a low priority loop) to the host PC. The timers let us know how the various loops are running.

That all I can offer,

Ben