consumer loop slowing down producer loop

[Norbert_B]

---

@pschmal2 wrote:

[..]I tried to use the 'defer panel update' property, but the plot stops refreshing altogether. The program does run fast though as if I had deleted the plot completely.[..]

---

Once you set the defer panel update, no further updates are made to the complete panel. So it "freezes" until you reset this option (writing a false to this property).

---

@pschmal2 wrote:

[..]expect real time feedback on the UI.[..]

---

What is "real time"? Even for up-to-date PC systems, displaying Megabytes (or more) of data is most often a very consuming process. In addition to that, the average human being
- acquires about 25 images per second (frames per second/fps)

- cannot analyze differences in big data sets with that maximum data rate.

So taking this into account, it makes no sense to make updates of the UI too fast with too many data. It is quite common to introduce data reduction for the UI, while the original, unmodified data is streamed to disk for further offline analysis.

But since we still are not sure if the amount of data and the speed of the update is the source of that slow down, you have to make small benchmarks getting to the source.

Norbert

[pschmal2]

---

@Norbert_B wrote:

---

What is "real time"? Even for up-to-date PC systems, displaying Megabytes (or more) of data is most often a very consuming process. In addition to that, the average human being
- acquires about 25 images per second (frames per second/fps)

- cannot analyze differences in big data sets with that maximum data rate.

So taking this into account, it makes no sense to make updates of the UI too fast with too many data. It is quite common to introduce data reduction for the UI, while the original, unmodified data is streamed to disk for further offline analysis.

But since we still are not sure if the amount of data and the speed of the update is the source of that slow down, you have to make small benchmarks getting to the source.

Norbert

---

An array of doubles 256x50 in size should be around ~100kB, which isn't Megabytes (or more) of data. Even so, up-to-date PCs push many Megabytes to screen at high fps, just not through LabVIEW.

-The human being can detect high frame updates more than 25 per second, its easy to try this yourself (Your monitor may be capped at 60 hz) It easy to see difference between 30 and 60 hertz. 25 is sort of the threshold where a human brain is fooled into thinking a series of pictures is a video. Therefore my update should be at least that. Anything above 60 fps is wasted, so that is ok.

-The 3D plot class takes 200ms to update, so this is 5fps with no data collection. It is too low. If LabVIEW is unable to process 100kB more than 5 times per second then I will have to look for another solution.

[pschmal2]

Here is a nice website explaining the misconceptions people have about human perception and video:

http://www.100fps.com/how_many_frames_can_humans_see.htm

[pschmal2]

I've done an experiement:

In the consumer loop, I completely removed all data input. I removed the dequeing subvi, and everything else (Plot Helper etc)

The only things in there are the 3D plot hooked to an empty 3d plot constant

and Wait (1000ms)

Whenever the consumer loop fires (every 1 second) the producer loop freezes for the same 200ms. If I mouse over the 3D plot pane with no data, it still freezes the producer loop indefinitely until the mouse stops moving over the pane.

Of course if I delete the 3D plot and just have the Wait (1000ms) in the loop, the 200ms freeze disappears.

I'm going to chalk this one up to the 3D plot vi just not being very efficient for real time updating. I wrote a similar plotting function (2D projection of intensity) with the NI Vision Systems module and the graphical VIs in that module, so I'll just use that, but I have to rebuy it to get it up to LV2011 😞

[johnsold]

"Whenever the consumer loop fires (every 1 second) the producer loop freezes"

This suggests that both loop are running in the UI thread. Since they are in the same thread tying up the processor in loop loop will block execution of the other loop.

Do you have any controls, indicators, local variables, or property nodes for a control or indicator in the producer loop?  There may be some other things which can cause a node to use the UI thread, but these are the common ones.

Lynn

[Norbert_B]

Ok, fps for human eyes is going off topic, but your link does provide an essential information you do mix up somehow.

The update rate and the refresh rate of monitors is different.

Refresh rate is the rate you set in your graphics driver and for most TFT it is about 40Hz. Human beings do not see any flickering for most applications with this rate since the image is displayed continuous. CRT monitors on the other hand do not display continuously, so they have to refresh a faster pace. 60Hz refresh rate is perceived by many people with flickering esp. when not directly looking at the monitor.

The update rate is the rate software sends new images to the display driver. I haven't done any tests and your link does not talk about this: What happens if update rate>refresh rate? I would expect the graphics driver to discard images, which could introduce flickering for that application. So, the limiting rate for display updates (which do make sense to create in your application) is the refresh rate.

But the most important point for this discussion (esp. updating graphs and tables):

What is the maximum rate an average human can "acquire information" from the image the human sees? This is depening on many factors, e.g. reading speed (which could be improved by practice), BUT there is a limit far less than 25Hz. Seeing differences is something we can do at about 25Hz, picking up small packages information with much less (maybe <10Hz), reading and understanding data with <5Hz....ok, those numbers are not backed up by any research studies and are heavily depending on the individual and the type of information (Many texts of laws are not understandable even if re-reading them for hours!).

But i hope you understand what i am up to: Updating (so update rate) graphs and tables at a high rate (>10Hz) makes no sense for most applications!

Back to topic:

Can you check if the delay is connected to certain settings of the 3D graph (like surface, anti-aliasing, ..) or to the type of 3D graph (pie vs. mesh)?

Do you have property nodes in your producer?

Norbert

[Ben]

---

@Norbert_B wrote:

... 

Norbert

---

Hi Norbert,

I am jumping in to try and help out with what little I know.

The new 3D graph functions are pigs for two reasons. I suspect a poor implementation of the underlying classes combined with the OpenGL implementation.

Using a machine with 8 cores, only one of the cores get used once the data is presented to the graph. It "looks like a duck UI issue".

Tossing the Helpers and writing my own set of classes improves the performance right up until I present the dat to the Picture (3D picture).

SInce we can not toss the OpenGL we have a limited number of options for RT updates.

1) Use the CW version.

2) Reduce the number of elements in the 3D picture.

3) Minimize the screen with the 3D picture/graph when they are updated.

The report above about about the Mouse Over stuff tells me there is a poorly implemented XControl and I will venture a guess that they are repeatedly updating the image when the mouse over happens.

I would dearly love you to show me where I am wrong with my above comments becuase in doing so I will learn to improve the quality of my 3D apps.

As i said, I am only trying to help.

Ben

[Norbert_B]

Ben,

i do believe that performance of 3D graphs could be improved (*what level?*). And you pointed out one thing i want to clearify with the OP:

3D graphs do hog the UI thread. But since the UI thread is a unique thread, no parallelism is possible there (at least to my knowledge).

So if anything in the producer is bound to the UI thread, the 3D graph naturally will block/slow down the producer!

Hence my question regarding property nodes. And since we haven't seen any code from the OP yet, this is my best guess right now....

Norbert

[Ben]

---

@Norbert_B wrote:

Ben,

i do believe that performance of 3D graphs could be improved (*what level?*). ...

Norbert

---

Agree on UI thread issue.

What level?

That is a simple question to answer!

A LV version of Wolfenstien that performed as well as that game on an old PC would be an excellent start.

Ben

[pschmal2]

I will try to snuff out any UI elements in the producer loop, but most of my controls are outside of both loops. Changing them during running doesn't really matter too much.

I am using the new 3D class because in matrix mode it makes conformal mapping of data very easy, like using meshgrid in matlab then surf.

I want to also repeat that the hardware I am controlling is interactive, and the lag between doing some motion and the update of that motion on the screen is very noticable with a 200ms program freeze.

Re: FPS, I used to work in a control room for a TV station, and we recorded at ~60fps and then there was some downconversion to ~30fps to send out over broadcast. Two monitors next to each other gave the raw feed and the broadcast feed, and it was super noticable, to the point where watching normal TV started to get annoying because it felt molasses-y.