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

As I suggested earlier search for the KB article about how LV handles cooperative multi-tasking for a full description of what is happening.

 

In short, without a timer, the thread remains in a "compute" state and never releases the CPU for other threads and just keeps queuing this up.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 21
(1,279 Views)

You are writing to two different files in the consumer loop and this will always be slow compared to anything else. Your consumer loop consumes one queue entry per iteration.

 

Your producer loop (without timing) will run as fast as possible and will run many times before releasing control to other code parts (e.g. the consumer loop). a 0 ms delay will release control to another code part that is ready to run. This will slow down the producer loop, because it has to go to the back of the queue.

Without detailed analysis, it is impossible to tell how things are split up if you have multiple CPU cores (you probably do).

 

Common sense and simple math tells us that you should not produce more than you can consume on the average. If you produce in short fast bursts, it is OK to fill the queue and consume at leasure later, but you are trying to run these loops almost synchronous. If you want to run this as fast as possible, skip the queue entirely and write to file in the upper loop as it is produced. It won't be as fast, but it will be synchronous and will not involve any extra memory build-up. 

0 Kudos
Message 12 of 21
(1,274 Views)

In addition, I am not familiar with the rt timer. The help says it will try to get an average under windows. For example a 1us setting might insert a 1ms every 1000 iterations. not sure.

Anyone have more info?

0 Kudos
Message 13 of 21
(1,260 Views)

I'm ok with the explaination about execution time.

 

There is still a question :

 

Why is there a memory allocation ? 

Is there any way to avoid this ?

 

Thanks

 

julesjay

0 Kudos
Message 14 of 21
(1,204 Views)
Solution
Accepted by topic author julesjay

@julesjay wrote:

Why is there a memory allocation ? 

Is there any way to avoid this ?




The allocation is happening inside the queue FIFO.  If you did not specifiy a maximum size for the queue, then it will reallocate memory when it runs out.  Since your producer is running much faster than the consumer, the queue will keep increasing in size and therefore causing more memory allocations.  As already stated, this can be avoided by either slowing down the producer (adding a 0ms wait will work) or ditching the producer-consumer framework and putting the write to disk with the processing of data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 15 of 21
(1,194 Views)

Ok thanks for all your answers.

0 Kudos
Message 16 of 21
(1,188 Views)

@julesjay wrote:

Ok thanks for all your answers.


You thanked multiple people for their answers. Which was the answer? I mean I think that I know but somebody learning in the future and finding this with a search might not.

 

The accepted solution button is intended to mark the response that answered your question. Sometimes people do figure out the answeres to their own questions, post the solution and mark it which is completely ok.

 

If you wish to change it you still can. Go to to Options on the right of the reply you marked as the solution and select "Not the Solution" then mark whichever post answered your question.

=====================
LabVIEW 2012


0 Kudos
Message 17 of 21
(1,178 Views)

Done  😉

Message 18 of 21
(1,171 Views)
@Altenbach et all:

Note  (Windows)The Windows operating system supports only millisecond resolution. If you select a µSec or Tick resolution under Windows, the VI does not provide exact timing and instead provides an approximation that averages to the requested time over the course of the timing interval. Windows does not support resolutions under one millisecond and rounds them up to one millisecond.

From the LV help for the Wait Until Next Multiple Express VI (RT).

Essentially, it says, that we are always waiting a multiple of 1ms on Windows if the the value for counter units is >0. Attached you can find a small VI which evaluates this.

 

The only advantage of using RT timing functions for Windows is, that we KNOW us offsets for loop iterations and "stick to them" since the timing is working on ticks which also have higher resolution as 1ms on Windows.

 

@All: As expected, you will get random delays way higher than 1ms from time to time due to Windows being not able to run deterministic.

 

@julesjay: You should get similar results if using the waiting functions from the Windows palette when wiring a '0' to them. No need to use the RT version.

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 19 of 21
(1,165 Views)

Ok Norbert, I give up. Where is the Wait (us) VI? I tried dragging your example to an empty project but nothing shows up in the dependencies. I cannot find it with quickdrop either.

=====================
LabVIEW 2012


0 Kudos
Message 20 of 21
(1,159 Views)