Network buffers versus RT FIFO versus Implementation Details

[bokorpet]

I understand that an RT FIFO is always on the client side.

What I don't understand is why two buffers are better than one (a longer one)? In other words, I can't think of an application which works with network buffers but which wouldn't work with RT FIFO. Can you?

By the way, the setup in Figure 11 looks to me like a combination of two buffers even if there is no buffer at the SVE host.

Thanks,

Peter

[nathand]

Sorry, I meant to refer to Figure 10, not 11. My point is that the RT-FIFO is on a per-client (and per-variable) basis so enabling an RT-FIFO on a variable configures only a single buffer, on that specific client.

I don't think it's an issue of 2 buffers being better than 1. I think it's two features being implemented and tested independently, that happen to result in two buffers when used together. It's generally considered good practice to implement features in a way that they don't interfere with other features when possible, and that's probably what happened here.

One use for network buffering without an RT-FIFO is an application running on a non-RT target that uses shared variables. There also needs to be support for reading and writing shared variables deterministically on an RT target, which requires the use of an RT-FIFO. I assume these two features were developed and tested separately. The performance impact of two buffers versus one is probably negligible,so the added complexity of a special section of code to consolidate them is probably not worthwhile.

[bokorpet]

I see your point.

My claim (or misunderstanding) is only that these two features don't seem to be orthogonal. I see what network buffers are for, I see what RT FIFOs are for, but I can't think of an application which would benefit from their combination. And such a combination is explicitly encouraged by NI (Figure 14 in the white paper). Again, if I use RT FIFO, I already have a buffer.

It may be that, as you suggest, the client/server side buffers make the difference. But I still don't see the difference (compare Fig. 11 and 13.).

You say there is one buffer with RT FIFO. I see two buffers (Fig. 11): one on the writer client, another on the reader client. This suggests that RT FIFO is on a pre-variable basis. Am I missing something?

Peter

[nathand]

---

Bokor wrote:

My claim (or misunderstanding) is only that these two features don't seem to be orthogonal. I see what network buffers are for, I see what RT FIFOs are for, but I can't think of an application which would benefit from their combination. And such a combination is explicitly encouraged by NI (Figure 14 in the white paper).

---

I would say this configuration is supported and explained, rather than encouraged. I'm sure if they supported this configuration without an explanation, someone would be asking the similar questions about what happens if they're both enabled. Unfortunately I don't think I'm going to be able to provide that's fully satisfactory for you as to when this configuration would be advantageous; maybe someone else who has used this setup will comment (I haven't, nor have I had a reason to do any benchmarking or comparisons).

---

Bokor wrote: 

You say there is one buffer with RT FIFO. I see two buffers (Fig. 11): one on the writer client, another on the reader client. This suggests that RT FIFO is on a pre-variable basis. Am I missing something?

---

I'm pretty sure those two RT-FIFOs are configured independently - they don't need to be the same length. There's no requirement that all clients support RT-FIFOs in order for any of them to back a variable with an RT-FIFO, so if in figure 11 the writer wasn't running RT, the system would still work but without the buffer on the write side.

[bokorpet]

---

@nathand wrote:

I'm pretty sure those two RT-FIFOs are configured independently - they don't need to be the same length. There's no requirement that all clients support RT-FIFOs in order for any of them to back a variable with an RT-FIFO, so if in figure 11 the writer wasn't running RT, the system would still work but without the buffer on the write side.

---

Are you sure? RT FIFO is a property of the shared variable and not a client. At least this is how I know that (right click on the shared variables -> Properties -> RT FIFO). How would you tell LabVIEW not to create RT FIFO at a specific client (a client being a VI accessing the shared variable)?

[nathand]

I assume that if you enable aliasing on a shared variable so that it refers to a a variable elsewhere on the network, you can decide whether to enable an RT-FIFO on that client independent of what any other client is doing, but this thread suggests that I might be wrong: http://forums.ni.com/t5/LabVIEW/fifo-shared-variable-programmatic-access/td-p/2617115. Unfortunately I don't have access to the RT module and an RT system to test this at the moment.