Real-time execution trace toolkit for Labwindows/CVI code optimization

[Amin1]

Hello,

I am trying to optimize a real-time code in LabWindows/CVI by minimizing the time each section of the code is taking and finding the bottlenecks in the code. I check this time using the real-time execution trace toolkit.

However, I just found that there seems to be some constant error when using the real-time execution trace toolkit.

When I put the traceviewer "start" and "stop" right after each other, I get around 9us time difference. It seems that the CPU goes into some idle mode after the trace starts, or maybe it is the communication delay or something. 

I would appreciate it if someone can give me an idea of why this is happening. The application time window for real time is very limited and I am trying to minimize the time as much as possible. Even the 9 us error is hard to spare.

 I used the following code :

TraceConfigure (1, 1, 0, 25000, NULL);
TraceStart ();
TraceStopAndSend (HOST_ADDRESS);

and this is a picture from the real time execution trace toolkit.

Thanks.

[WestOfEden]

Hey there,

What target are you executing this code on? Unfortunately there isn't any benchmarking data for the RT Execution Trace Toolkit so I can't say whether that is expected or not. 

It might be helpful to post a question about the overhead of the RT Execution Trace Toolkit in the LVRT forum as well, since people there may have seen similar behavior when using it as well, and may be able to provide some insight from their experience.

[Sneaker · Accepted solution]

Generally you might be better off picking off the clock at the start and end of what you want to trace. RTETT my introduce overhead that becomes hard to quantify... Which is what you're already likely seeing. Debug mode will also introduce a ton of overhead. So... picking off the clock in release mode will probably give you you're best estimate.

[Amin1]

Thanks Sneaker.

I went ahead and moved from debug to release.

I also used the GetTimeUS() function to calculate the number of microseconds that the code runs, instead of using the code RTETT. It seems to give me much more realistic answers.

Thanks

[Sneaker]

Glad to hear it. I have found Debug in Real-Time to be extremely dicey. Generally I use it as a first cut to check for run-time errors and resource checkouts upon application shutdown. Other than that the overhead is so high that I usually start running into problems pretty quick like buffer overflows in DAQmx callbacks being run at high rates and such.

BEWARE: In Release Mode you may find that non-fatal run time errors will be gracefully passed over. Fatal errors are almost impossible to trouble shoot unless you know what probably caused it. This is when I usually hop into debug mode and get in and out as fast as I can.