05-03-2012 11:23 AM
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
05-03-2012 11:42 AM
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.
05-03-2012 12:40 PM
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?
05-09-2012 08:07 AM
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
05-09-2012 09:08 AM
@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.
05-09-2012 09:12 AM
Ok thanks for all your answers.
05-09-2012 09:34 AM
@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.
05-09-2012 09:37 AM
Done 😉
05-09-2012 09:58 AM
@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
05-09-2012 10:11 AM
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.