Application pauses for up to 4 seconds at random places in processing loop.

[johnsold]

COsiecki,

I am not sure if this has changed with recent versions of LV, but in earlier versions running FFTs on sample sizes which were an exact integer power of 2 was faster than similar sized arrays which were not. A different algorithm was used internally. A 65536 point (2^16) FFT was faster than a 65000 point FFT.

Lynn

[Ben]

"four second delays" sound like Virus check La-La-Land or Virtual Memory Allocation.

Ben

[Chris.Osiecki]

I'm having our IT guys take the virus scanner off that machine, but the last time I ran, I was fairly sure I had disabled it. I will try again once it is uninstalled. What should I look for regarding Virtual Memory Allocations?

I should also be able to implement the sample length adjustment fairly easily. Thanks for that suggestion!

[Ben]

Watch yours app's memory useage using the Windows Task Manager. If vritual memory is climbing or you see a jump in page faults abou tthe time of the pause....

Here is a cut-n-paste of ideas i used to keep a Timed Loop running without interuption. Maybe one of these ideas can help.

---

Hi All,

After some experiments and punching a lot of buttons, it appears that multiple timed loops can run under Windows with HARDWARE timing.

This does not seem to be possible without adjusting the environment to help this happen.

The following is a list of things that can help you "adjust" Windoze do its job.

1) Set Windows to optimize background services.

Windows by default will attempt to optimize its scheduling to make foreground processes perform well. For single threaded applications this is fine but for LabVIEW, some of its background threads can suffer.

A) Start >>> Control Panel

B) Open "System" and choose the "Advanced" tab

C) In the "Performance" section click "Settings"

D) On the "Advanced" tab in the "Processor Scheduling" section select "Background Services"

E) Save or apply everything.

2) Stop Indexing services.

Windows will by default do file indexing. File indexing is functionality that tells windows to maintain in memory a cache of files on a disk or in a folder. This makes files show up in the Explorer faster and also makes searching for files faster.

A) Start >>> Accessories >>> Windows Explorer

B) Right-click C: drive and select "Properties"

C) On the "General" tab un-check "Allow Indexing Service to Index This Drive for Fast File Searching"

D) Save and apply everything

3) Set LabVIEW priority in Task manager. Windows will by default treat all processes that are ready to run as peers and will share the CPU evenly.

A) Open the Task Manager and select the "Processes" tab.

B) Locate "LabVIEW.exe" in the list of processes.

C) Right -click "LabVIEW.exe" and choose Set Priority >>> High

Note: Setting LV to run at higher than "High" will put it on equal footing with interrupt service routines etc. This could result in the machine "locking up" because LV is using all of the CPU and there is no opportunity to respond to interrupts from your mouse moving.

4) Shutdown Virus Checking. Virus checking gets its hooks into everything!

5) Disconnect Ethernet cable. Ethernet traffic requires intervention by the OS. No cable, no traffic, no distractions.

6) Set the VI properties of the sub-VI that will run the Timed Loop to "Priority = Time Critical" and "Execution Thread = Data Acquisition".

7) Configure hardware Timing source to run at 2000 Hz.

😎 Set "period" of timed loop = 2 (i.e. 2000 Hz clock / period of 2 = 1000 Hz)

Now wasn't that easy?

I have tested the above using the instructor machine with LV8 running three timed loops at 1000Hz for 20 minutes with no missed iterations and no "Finished Late" indications where the loop failed to start on time.

Ben

---

let me know if any of the above helps,

Ben

[Chris.Osiecki]

Here's an update: I have implemented all the suggestions Ben made. I also have changed my program to zero-pad my data to 2^17 samples. The frequency of lock-ups has decreased, but they are still occurring. Here's my changed function:

Here is a strip chart of the Speed Time from the above function while running:

This runs once a second, so the chart represents about 1.1 hours. There's smaller spiking as well that you can't see with the Y scale at 12k. The normal time for the function is ~20mS, but it spikes to 50-80mS several times a minute. I don't think its related, but I figure the more info, the more help. Again, it's an improvement, but I can't have any lock-ups during testing. Is there some function I could use other than an FFT to get the frequency? There are several other transform options available, should I just start trying them until I get one that doesn't lock up?

[Ben]

Hi Chris,

What does the Windows Task manger show is using all of the CPU durring those spikes?

Is the task associated with your LV process showing page faults?

Is the number of samples you are processing always the same?

Not giving up on your!

Ben

[Chris.Osiecki]

Task manager shows LabVIEW as taking 99-100% CPU when its paused. There are no spikes in memory useage. I've even tracked it using perfmon.exe and looked at other memory usage, like cache and read/sec and everything is stable. One thing I've noticed is that if I right-click on the taskbar tab for my application while it is running, CPU usage goes to 50% and the program hangs in a manner similar to the problem I'm experiencing.


Message Edited by COsiecki on 06-11-2008 08:33 AM

[Ben]

Still sounds like you are being pre-empted or you are going into a page fail wait state.

Use the "Show Kernal Times" option of task manager to see if the red line is spiking durring the pauses.

Show "Page fault Delta" for the processes and see if that is spiking durring the hits.

Please reply to the other Q's above and did you try all of the stuff I listed in that previous punch list (disconnect network, set priority, ...)

Ben

[Chris.Osiecki]

Ah, sorry, forgot about the other questions.
I'm not certain how to tell if it is showing page faults.
The sample size is always 100k. I've started zero-padding that out to 2^17 samples.
I'll run with the kernal timing showing and report back.

One thing that was just suggeseted by a co-worker was to try exchanging the computer to see if there is a hardware issue. Luckily I have another computer configured for a similar task and it would be very easy to try. He also thought that 100% CPU was something that would take an OS problem to occur, since usually an out of control program will just max a single core.

[Chris.Osiecki]

Another update: I ran with the kernel timing and when the progrm hung and the CPU went to 100% on both cores, kernel time was 50% on both cores. I was testing the right-click thing with the kernel timing, and again it almost exactly mirrors my problem, but only on one core.