01-05-2012 09:31 PM
Hi all,
Another curly question for the pro's:
I have recently inherited some labview code that uses RT-FIFO for the transfer mechanism in the producer consumer architecture.
The code was first written 3-4 years ago and is presently in LV8.6. It is possible that the reasons for the architectural decision no longer exists.
I am skilled using a queued producer consumer architecure,
I understand the RT-FIFO Architecture.
I have begun using a user Event Based architecture.
(I have attached samples of each)
I also see the existance of a priority Queue
Each method has it's own capabilities and deficiencies, That aside, does anyone know the relative performance of each method.
(Assuming single process)
I would expect RT-FIFO to be fastest, it appears to be a low feature version of a standard queue.
What is the perfornace hit for using a more coding freindly Queue
The RT-FIFO description speaks of commications between time critical and lower priority threads.
Until today, I believed that Queues had the same capability.
I have included an event method I commonly use for peer review and to help to fellow users..
It allows:
1. Multiple producers with different data types
2. Processes repecting order of production.
3. Allows for asynchronus checking of functional notifiers such as stop, start and abort.
4. In a non real time system it can include front panel interactions.
What I don't understand about it is what overheads, or thread priority changes that may be experienced by using this architecture (it solves a lot of problems for me).
Thanks in advance,
Solved! Go to Solution.
01-05-2012 10:57 PM
I would think RT-FIFO, Event, Queue in that order.
01-05-2012 11:18 PM
Thanks for the response,
Can you explain why and by how much and any impact on task priority?
I would have guessed Queue faster than Event, the event model would need to maintain multiple queues (Event is a one-to-many relationship) .
01-06-2012 07:45 AM - edited 01-06-2012 07:48 AM
My assumption of RT being the fastest is simply based on other posts that I have read, but I suppose it depends on what "fastest" means. The time for the FP to respond or process data in the Consumer loop? Unfortunately my experience with RT is vertually nil and this was based on other readings. But as far as Queue and Events, Events will respond qucker to the FP. But I think it's apples and oranges based on your example.
01-06-2012 01:32 PM
Hi Timmar,
Here is a KB article on some commonly asked questions about RT FIFOs: http://digital.ni.com/public.nsf/allkb/7AE7075AF1B2C58486256AED006A029F?OpenDocument
The most relevant question is #4, which I have posted below.
What is the difference between RT FIFOs and Queues?
Functionally, RT FIFOs and LabVIEW Queues are both First-in, First-out buffers. However, the following are the major differences between them:
Let us know if there are any lingering questions!
Ryan
01-06-2012 01:47 PM - edited 01-06-2012 01:48 PM
Are you running into a situation where the difference in time between producing an event, and consuming it, is actually causing your problems? If not, this is not a question worth worrying about. Use whatever is most appropriate for your application.
There's no need to make wild guesses - build a VI, benchmark and test! The attached is a reasonable starting point, although I think the event structure may be slow due to setup time but may respond quickly once running. If you experiment with this, you'll probably find that there's no definite answer to which is fastest. Changing the size of the RT-FIFO, or of the queue, makes a big difference in speed. At least in my testing, a single-element RT-FIFO is fastest, but an infinitely large queue is faster than a small queue, and a longer RT-FIFO is much slower than the single-element version.
It's important to realize that RT is not another word for Fast or Efficient, it's another word for Consistent. For the purposes of real-time (deterministic) execution, it doesn't matter how fast the RT-FIFO functions are so long as they execute in exactly the same amount of time, every time (with the exception of a "forever" timeout value, of course). You can use either a standard queue or an RT-FIFO to communicate between loops. One use for an RT-FIFO is when a time-critical loop is enqueuing the data. It guarantees that the amount of time needed to put data into the FIFO will not vary. Enqueueing data in a standard queue will sometimes be faster than other times, depending on whether there is already space available in the queue or space needs to be allocated for the new element. If this variation is unacceptable, then use an RT-FIFO; otherwise, the standard queue works just as well.
If the architecture shown in your image is working for you, I don't see any reason to change it.
EDIT: oops, almost forgot to attach the code I used for testing!
01-06-2012 01:59 PM
awesome nathan!
01-06-2012 04:18 PM
@Ryan D wrote:
awesome nathan!
Thanks! You know, there's a nifty "Kudos" button to the left of each message that you can use to express the same sentiment.
01-06-2012 04:21 PM
01-06-2012 05:12 PM
kudos given where kudos due!