Network buffers versus RT FIFO versus Implementation Details

Question

Hello,
can anybody provide information on how the Shared Variable Engine (SVE) is implemented (threads, priority, etc.)?
Specifically, I'd like to formally understand the properties implemented by a combination of RT FIFO with network buffers.
The official NI white paper (http://www.ni.com/white-paper/4679/en/) doesn't explain the rationale of chaining up buffers (an RT FIFO is also a buffer). See Figure 14.  
Without additional explanation, I would need to know what the SVE really does.
Can anybody name an application where such a combination is needed, and where a single RT FIFO or single network buffer wouldn't make it?
Thanks!
Peter

Answer 1

Bokor wrote: 
It sounds to me that server-side buffers are also created in the pure RT FIFO case (with network-published variablesa and without network buffering). What do you think?
I don't think so, since it says "When you configure a network buffer in the dialog box above, you are actually configuring the size of two different buffers.  The
server side buffer..." which suggests that the server side buffer is configured only when network buffering is enabled.
Bokor wrote:
By the way, what exactly do you mean by "RT-FIFOs for deterministic operations"? Do you mean time determinism so that the reader/writer can read/write within a pre-given amount of time? Or do you mean deterministic scheduling of threads? Or something different?
Deterministic behavior means that the operation will always take exactly the same amount of time to complete. When you enable an RT-FIFO on a shared variable, you are insulating your code (such as a time-critical loop on an RT system) from resource contention with the shared variable engine (SVE), so that your loop rate is not affected by anything the shared variable engine is doing in the background. Without the RT-FIFO, if your code tries to access a shared variable and the SVE is already accessing the same variable, your code will wait until the SVE finishes, which introduces jitter - small variations in timing. In many cases that jitter is so small that it won't make a difference, but in some high-performance real-time applications it is critical to eliminate any sources of timing variation.
Bokor wrote:
Regarding your note on independent development of these features: since there is an official white paper comparing these features, I would expect NI to be clear about their usage. Statements like "With [network] buffering, you can account for temporary fluctuations between read/write rates of a variable." is misleading because the same property can be implemented via RT FIFOs.
So, how can one build commercial RT application without knowing the formal properties of the programming constructs one is using?!
I don't really understand your question. Again, I think the RT-FIFO and network buffering are two separate features and you're talking about the effects of enabling both of them simulatenously in which case yes, there's some overlap. If you need complete control over networking behavior, you can always fall back to TCP. Network shared variables simplify exchanging data over a network, with the tradeoff that you don't have complete knowledge of, and control over, the implementation (in fact, the implementation could change between LabVIEW versions, as explained in that white paper about the rewritten protocol). I wouldn't let that limit me from using them though if they're the right solution for my application.