LabVIEW
Application pauses for up to 4 seconds at random places in processing loop.
There may have been an ah ha! moment, but I don't know what to do with it. First, some pictures:
Above is the Task Manager during a lock up.
This is probably more useful. I made two little programs that share a queue. This is a very basic version of how I move data in my program, though it is running on another computer. What I have done in the image is to right-click the task bar tab of one of the vi's. I did this, then clicked off of it, and then right-clicked again. That is why there are two periods of high CPU usage. As you can see, this causes CPU usage to jump. What you can't see is that the programs themselves stop updating. I think this is some kind of OS issue. So my new theory is this: Something Windows is doing is causing an interrupt issue. In this little example, there are only two loops. In my program there are ~15. When all 15 loops go into this mode, it maxes the CPU leaving basically nothing left for calculations. This causes the FFT to take a REALLY long time. Once it is done, Windows gets itself straight and everything gets back to normal. The reason it is happening less is because I zero-padded my data and the FFT is faster, thus there is less of a chance this interrupt will happen while its calculating.
Now, the important question: Is there something I'm doing wrong with the queues? Is there another option for handling my data?
I finally think we're getting close on this.
Above is the Task Manager during a lock up.
This is probably more useful. I made two little programs that share a queue. This is a very basic version of how I move data in my program, though it is running on another computer. What I have done in the image is to right-click the task bar tab of one of the vi's. I did this, then clicked off of it, and then right-clicked again. That is why there are two periods of high CPU usage. As you can see, this causes CPU usage to jump. What you can't see is that the programs themselves stop updating. I think this is some kind of OS issue. So my new theory is this: Something Windows is doing is causing an interrupt issue. In this little example, there are only two loops. In my program there are ~15. When all 15 loops go into this mode, it maxes the CPU leaving basically nothing left for calculations. This causes the FFT to take a REALLY long time. Once it is done, Windows gets itself straight and everything gets back to normal. The reason it is happening less is because I zero-padded my data and the FFT is faster, thus there is less of a chance this interrupt will happen while its calculating.
Now, the important question: Is there something I'm doing wrong with the queues? Is there another option for handling my data?
I finally think we're getting close on this.
OK looking back and regrouping.
First we should stick with your applicaiton. THose examples pumping queues without reading them may be page faulting trying to allocate more space for the queues.
IN your app you decided that FFT was the the big hitter and padding the FFt to an apppropriate size helped.
Is the size of the buffer being passed to the FFT the same size?
We need to focus on what is hitting your app. Performance in LabVIEW is a delicate topic and trying to solve all performance issue in one thread is like chasing butter-flies.
Ben
