LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I be faster than milliseconds under windows 7 ??

Solved!
Go to solution

Hi,

 

I'm using Labview 2011 SP1 under windows 7 32bits. I encounter something strange that I can't explain. My program run so fast that I don't understand why?

 

In my program, a while loop runs more than 1000000 times during approximativley 2500ms. I throught that under windows time unit was ms and us under RTOS.

 

Can anyone help me to understand what happened here?

 

 

thanks

 

 

0 Kudos
Message 1 of 21
(3,518 Views)

If you don't have any delay inside the while loop it will run very fast depending on your processor speed but am not sure about the number you have mentioned. Please explain what is the exact problem you face here.

-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 21
(3,514 Views)

That right, I haven't explain my real problem.

 

A developper ask me for help due to memory leak problem.  

The vi is using producer/consumer structure. When I run the program, the used memory increase a lot. This memory is never release even at the end of the execution and I need to quit all labview instance to release memory.

 

I've looked for memory allocation but there isn't any. In the structure, there was no timing. So I put a wait until 1ms in the producer loop (classical) but the execution duration was multiplied by at least 15 times but there was no more memory leak !

I've run many tests to understand. Here is some results :

 

Case 1. No timing                                        => total execution duration 15s  // Memory leak ++  //  Cpu load 70-90%

Case 2. Wait until 1ms                                => total execution greater than 3 minutes   //   Memory leak-  //  Cpu load 10-20%

Case 3. Wait until 1us (using RT palette)    => total execution greater than 2 minutes   Memory leak -  //  Cpu load 10-20%

Case 4. Wait until 0 us (yes 0)                    =>  total execution 40s    No memory leak   //  Cpu load 90-100%

 

So finally the 4th solution work fine but I don't understand :

- The difference between point 3 and 4 as I'm under windows

- Especially the execution time + memory leak in the first case.

 

I'm not sure I'm clear here...

 

julesjay

 

 

 

 

0 Kudos
Message 3 of 21
(3,511 Views)

Could you post the vi or a simplified version of it?

 

Regards,

Marco

0 Kudos
Message 4 of 21
(3,508 Views)

Sounds like a race condition to me. 🙂

/Y 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 21
(3,489 Views)

Post images of the code to help us help you.

 

But since you did not post any that give me license to speculate...

 

You are using a producer/consumer and the producer is pumping stuff into the queue as fast as your CPU allows. When running without the wait the queue fills faster AND the CPU is not being released to allow the consumer to empty the queue so the data piles up in the queue and it looks like a leak.

 

Did you try a "zero MS wait" (a Wait MS with a "zero" wired)?

 

That will take the producer thread out of the CPU at let other threads get a crack at catching up. Provided there are no other threads waiting, the zero ms wait will introduce only a small delay while the Task Scheduler decides who get the CPU next.

 

Search on "Cooperative multi-threading" or something like that to learn how LV handles multiple threads... blah blah blah

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 21
(3,478 Views)

Here is an example. I can reproduce my problem with it!

 

Try 0, 1 and no timing check CPU rate and memory usage!

 

Thanks

0 Kudos
Message 7 of 21
(3,450 Views)

Place a "get queue status" after the case structure in the lower loop and display the "# of elements in queue" on a chart.

 

wait=1: zero all the way

wait=0: zero to a couple of hundred

wait removed: rapidly increasing, to hundreds of thousands within seconds

 

This is expected.

 

Message 8 of 21
(3,445 Views)

@altenbach wrote:

Place a "get queue status" after the case structure in the lower loop and display the "# of elements in queue" on a chart.

 

wait=1: zero all the way

wait=0: zero to a couple of hundred

wait removed: rapidly increasing, to hundreds of thousands within seconds

 

This is expected.

 


 

 

Spoiler

Anyone remeber the show "Name that Tune" where contestants would compeat to se who could name a tune based on the lest number of notes?

 

We can name that memory leak with three hints.

 

 

Smiley Wink

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 9 of 21
(3,434 Views)

So how do you explain the memory increase when there isn't any timing? Is it due to windows?

 

 

 

 

0 Kudos
Message 10 of 21
(3,428 Views)