search

assisi / arena-ui

Bee arena user interface for the ASSISI|bf project.
Other
1 stars 1 forks source link

GUI freeze on many plot values #85

Closed dmiklic closed 6 years ago

dmiklic commented 7 years ago
dmiklic commented 7 years ago

Happened on Marsela's old laptop. Stronger machines have less problems.

marselap commented 7 years ago

Happened on master work station twice today. One trend with ~18 graphs. ~1h runtime.

Edit: not sure if it's the same freeze - starts switching between grey and "active", cannot be used even when active.

stribor14 commented 7 years ago

The reason is probably a huge amount of collected data. There is a setting for trend data sampling time, but looking through code now, I don't see it implemented. There are two settings for this:

In file qcasuzmq.cpp, function void QCasuZMQ::addToBuffer(dataType key, QCPData data) only checks and removes old data accordingly to trendTimeSpan setting, but doesn't check trendSamplingTime

Better performance on long runs could be achieved with larger sampling time. But then again, maybe crash isn't related to this. Aditional test should be made with simulator. @marselap, can you roughly describe steps to reproduce this?

P.S. those two settings aren't influecing data loging to .csv file

marselap commented 7 years ago

@stribor14 it has now been running for ~1.5h without disturbances. arena4x4 is loaded, all 16 casus connected. One trend shows 16 graphs (temp_wax) + 1 graph (temp_f). Run for ~1h. Timespan set to 59min. New setpoint to all casus every ~5-10 min.

stribor14 commented 7 years ago

If it's caused only when there is many graphs in one plot. Then it is not buffers fault. Buffers are filled with new data independently from plotting. User can add or remove graphs without concern of losing data in buffers, so data is always stored for all casu sensors. Trends access data through pointers so no additional resources are needed for plotting.

To test in simulator:

marselap commented 7 years ago

Additional info: at freeze CPU usage 100%, memory ~6% (by arena-ui)

stribor14 commented 7 years ago

@dmiklic If this still happens, I suggest running in reverse debug mode (e.g. mozzila rr)

rmm-fcul commented 7 years ago

I experienced this bug on the master workstation, in two similar, but separate use-cases. 1) the GUI was running for several hours; though in early experiments I only monitored ~10 CASUs and for a single temperature trace per casu. 2) the GUI had problems in less than 10 minutes, repeatedly. I was monitoring 16 CASUs, with two graphs. (T_wax and T_PCB). In case 2), I tried with one trend graph undocked, and with both docked.

The trend sample time is set to 99, the maximum it allows; the trend buffer was longer (30 mins, then 15 mins).

rmm-fcul commented 7 years ago

is there a way to increase the maximum allowed trend sample time? If the volume of data being plotted is a factor in the bottleneck this could give a workaround.

Use case: The sub-second sampling is not necessary to get a good picture of temperature values (not in all cases at least), but a longer-term graph is useful. Thus, even before the underlying problem is solved, the user could make a choice to trade sample rate off against graph length?

stribor14 commented 7 years ago

Can you check cpu, memory, hdd usage?

P.S. I think sample time is still hard coded in you version and not working, pull request with fix is still waiting

rmm-fcul commented 7 years ago

@stribor14 ok, will wait for the PR. I don't have any lab time scheduled this week but next time I'll gather some more stats as requested.

stribor14 commented 6 years ago

Possible fix in this branch (EDIT: PR #106)

could not reproduce the issue, but this code refactoring branch deals with data plotting library update and subsequent code optimization

Before this, app would slow down horribly with 55 graphs on 1 trend. This update was tested with 14 parallel trends each with 55 different graphs without noticing slowdowns.

stribor14 commented 6 years ago

@rmm-fcul

even before recent update, I checked if freeze happens with two trends, each plotting 55 graphs. Trend span was set at 59:59 (max) and trend sample time was 0.5 (min)

The app was running normally for a whole night. Only thing I noticed was a slowdown from the beginning when plotting so many graphs (this is now fixed with the new update)

stribor14 commented 6 years ago

This one should be closed

dmiklic commented 6 years ago

Fixed in 26d2099 (#106)