acquisition slowdown (even for simulation)

[ddemara]

I've been using an NI-5124 for data acquisition in burst mode.  I've noticed that it slows down dramatically over time.  I stripped out the main portions of the code, substituting simulated data for the acquisition and the slow down is still occuring.  I'm running Windows XP, and bringing up the Task Manager to view performance, you can see the processing spikes get further apart as the application runs.  I'm not seeing any evident increase in memory, so I don't think memory leaks are the issue.  Anyone have a clue what is happening?

The application is actually collecting 500 sets of 2000 samples, adding the 500 sets together to get an accumulated data set of 2000 samples.  This needs to repeat 2000 times so the final accumulation is 2000x500 added together collections resulting in a single 2000 sample array.  There are displays on other tabs, so the user can look at individual collections for the last 500x2000 burst collected.

[10Degree · Accepted solution]

ddemara,

I traced through your code a bit and noticed that you seem to be piling up an increasing number of "Idle" states in your queue.  I put an indicator on the "Get Queue Status" vi "Elements" output and watched the contents of that array as the application progressed.  As the application runs, the number of idle states in the queue increases, and the time between loops goes up.  If you watch the Elements output on the queue status vi you will see what I am talking about. 

I didn't see anything in the code that would suggest a memory leak, I think it is the idle state pileup that is causing the delay.

cheers,

-cb

[10Degree]

More thoughts.  The Idle state enqueues another Idle state.  When I remove that operation, your code seems to run full speed without any problems.  You may not need an idle state that "yields" processing with the 100ms delay.  Your dequeue vi does not wire up a timeout, so it is essentially "waiting cooperatively" for a queued element to show up.  As long as you send it a shutdown message, you are ok.

You should also include a Release Queue.vi after the main loops shut down to gracefully free the queue resources.

Hope this helps!

cheers,

-cb

[ddemara]

Thank you for the debugging help.  I need to go back to queue basics.  Interestingly, the slowdown was happening even before I added the 0.1 sec wait.  That was added because the CPU pegged at 100% without it.