RT jitter! Can multiple reads to a variable / cluster cause a blocking condition?

Question

Howdy do.
While incrementally developing and testing an application on a crio9068 (linux RT)  I've begun to see the 'finished late?' indicator in my main timed loop flicker. Starting to pull my hair out trying to figure out how to prevent this from happening. I made a 'hold max' vi and can see the longest execution time for each frame.
The application runs fine at about 75% processor load with the front panel open, and the majority of iterations execute in time. Occasionally, I'll have a 'spike' in execution time, and all four frames in the timed loop take significantly longer than normal to execute, and the 'late' indicator says so.
A couple questions I've had build up while chasing this:
-If I use local varables to pass data between loops, but only write to the variable in one place, can I still cause a blocking condition/jitter by competing reads of that memory space?
-If I use an FPGA read/write node to pass data between the timed loop and the FPGA, should I expect this to cause a problem? I selectively disabled a lot of my code, and it seems like this is where some of the delay occurs. What stumps me is that these parts of the code haven't changed in recent development and the thing never used to run late.
-On the topic of the FPGA read/write node, I previously assumed that I shouldn't write to the same FPGA FP item in different subvis. However, the code is set up so that there are multiple parallel calls to the read/write node, just with different elements selected. Is this BAD?
-Similarly, if I unbundle and read the same element from a cluster control in a 'parallel' fashion, can this cause a blocking situation, or is it the same as unbundling and wiring from there to multple places?
-I am using the recently renamed "NI software calibration and management toolkit (SCM)," formerly Drivven CalView, to handle communication between the RT and a windows host. It also does neat fault management stuff. Anybody else using this, and is there any possibility I'm getting jitter by having too many calpoints in my deterministic loop?
Any guidance on any of the above points would be greatly appreciated. If I don't make sense on any of the above points I can make example snippets to describe.
Solved!
Go to Solution.

Answer 1

Tom,
Thanks for your input(s). I'll stop obsessing over the local variables and the branched cluster wires for now.
I didn't realize that all the code in the timed loop would be serialized beyond normal execution. In fact, this brings up another question I have. Somewhere I read that the overhead of multithreading would cause an issue. Since the 9068 has two cores, I had previously been setting the CPU selector in the timed loop to 'automatic', which seemed to load both cores roughly equally. Doesn't this mean that the process is being multithreaded? Funny thing is that even when I do select cpu 0 or cpu 1, they both are roughly equal in utilization while the timed loop is running.
The period for the timed loop is set at 15ms, and the execution of all the frames usually occurs in less than 10ms. After several seconds I'll get a 'spike' in execution time, and it will take 20-30ms to complete an iteration. I'm not positive if my benchmark is valid, but if I look at the execution time for each frame and 'hold' the maximum time, it seems like they all (four frames) take extra time at this one instance. So that hasn't helped to narrow it down much. 
It sounds like you have a method in mind for 'caching runtime data'. If you can point me in a good direction to gather more information about what the thing is doing it would help. I have run a strip chart of execution times, attached.
How much should I expect having the front panel open will affect the determinism of the loop? I realized it added overhead, but since the overall CPU load is less than 60% (each) with all the bells and whistles (other loops) disabled, I thought it wouldn't be having an effect like this.
Again, thanks for throwing ideas around, it really helps.
Matt
Attachments:
iteration execution.png ‏16 KB