High CPU usage: using clusters vs handling data individually?

[kelendas]

Thank you guys for all of the replies, I will try to take everything into consideration!

The software in question is running on a Microsoft Surface Go 4 tablet, running Windows 11 OS.
CPU: Intel Processor N200
RAM: 8Gb
We are using Labview (2020). 

@altenbach 
Thank you for reply, regarding your questions: 
- Yes we have an indicator for that gigantic cluster :D. I ve looked into DVR just now, how would it look like exactly? We would have a DVR for the whole cluster? The top loop writes it, and the bottom one reads it?  Im new with this concept, so any suggestion is appriciated!
- As mentioned before this is Labview running on Windows11. Yes both loops are running on the same 50ms, and they can keep up! The reason why they are separated, is that sometimes we need to increase the CAN read frequency to catch and display new messages, without changing the bottom (control) loop. 
 

[kelendas]

Thank you for your reply JPB!

This software is being used in a vehicle, where we have to able to see every data on the UI if needed. You are right this is a LOT of front panel elements, and we use several tabs to separate the displayed data, just to make it easily understandable 🙂 Unfortuantely we cannot cut down on the number of indicators and charts. 

However, I agree with you, that the UI thread should be unloaded as much as possible. I believed that the tab control eleveates this problem, because we only have one tab open, so most of the indicators are hidden. Despite this, do the rest of the indicators still update every iteration? Is there a way to just update the values that are on the active tab? 

[avogadro5]

- Yes we have an indicator for that gigantic cluster :D.

---

Of all the things you've said about the 2 approaches, this is the one that is definitely worse than the many indicators/local variables. Each time you write to that cluster indicator, all the elements have to be updated on the display. 2 ways to maybe fix:

• Go back to single element indicators for display only, and only update the indicator in the same frame as when the cluster data changes
• Update the giant indicator less often, I would start with a lazy approach where you only display the cluster in a timeout case which limits the number of updates to no more than the computer can handle.

[altenbach]

---

@kelendas wrote:

@altenbach 
- Yes we have an indicator for that gigantic cluster 😄 

---

In any case, a N200 is a very low performer with the advantage of only 6W TDP. Should work fine.

As a first quick test, see if hiding the indicator would make a difference. (right-click...advanced...hide indicator).

Also make sure to disable debugging.

.

[JÞB]

---

@kelendas wrote:

Thank you for your reply JPB!

This software is being used in a vehicle, where we have to able to see every data on the UI if needed. You are right this is a LOT of front panel elements, and we use several tabs to separate the displayed data, just to make it easily understandable 🙂 Unfortuantely we cannot cut down on the number of indicators and charts. 

However, I agree with you, that the UI thread should be unloaded as much as possible. I believed that the tab control eleveates this problem, because we only have one tab open, so most of the indicators are hidden. Despite this, do the rest of the indicators still update every iteration? Is there a way to just update the values that are on the active tab? 

---

I hate tabs.  Primarily because the answers too your last 2 questions are; yes! they do and no! there is not.

Any FP Object that is accessed from a terminal, p-node, method Event or Local variable requires the UI Thread. You HAVE TO minimize the cost PERIOD.  No User ever evaluated every FP Object at 50msec!  And you are logging that data anyway!   

So, since we are talking about the User Interface we need to talk about the User's Story.   

The User's Story is brought about by a discussion about how the User REALLY reacts to the software you develop.  When you, as a developer are told things like "I want a Tab that displays XYZ." Ask "How often is XYZ displayed? When? What else is useless while displaying XYZ? Would a Dialog.vi (or subpanel) be better?  Focus the User on what they will do with each datum and how attentive they must be!  My VIS display can show me the airpressure of each tire in near real time ...I don't use that information often and don't use that display to steer around corners.

Just as in driving their own car!  Do they look at the speedometer unless they see flashing lights on the patrolman behind them? Or do they just keep up with traffic?  How often did they look at a velocity vs time graph?  (Might be nice for post analysis- but is it on your dashboard?)

So, I am going to suggest again that you should investigate the shipping project templates for Continuous measurement and Logging.   AND go through the developer walk through.  Then step into the online training material for each concept. It will not make you a better person...it will make you a better programmer!  

You are trying to make a good vehicle driver with software...you need to talk to some good drivers (users) and get the story about what is important when.

[JÞB]

---

@altenbach wrote:

If you look at the picture, here each timed loop is assigned to a dedicated CPU core 

---

I saw,  but there ARE nasty things that can play with the default threads per execution system settings...hence, "as many threads per..."

Yet, I maintain, my dust grains per boulders, view of a FP with (channeling Christopher Lloyd "1.21 jagilloin" objects) over simple mistakes like poor scalar datatype choices. (There are several I saw...)

[alexderjuengere]

---

@kelendas wrote:

I have attached the old and new code. Thank you for your replies. 

---

have you inlined those sub-vis?

Spoiler

[Yamaeda]

11% is very close to 1 CPU spinning wildly, which is typical of a greedy loop. If you only have those 2 loops and they're timed, it shouldn't be possible to get to that level.

That being said, why is the lower loop timed at all? If the 1st enqueues the data the lower can be a normal dequeuing Consumer loop.

[altenbach]

---

@Yamaeda wrote:

11% is very close to 1 CPU spinning wildly, which is typical of a greedy loop.

---

The N200 only has four regular cores, so one core would be close to 25%.

[Yamaeda]

---

@altenbach wrote:

---

@Yamaeda wrote:

11% is very close to 1 CPU spinning wildly, which is typical of a greedy loop.

---

The N200 only has four regular cores, so one core would be close to 25%.

---

Fair enough. Though those two loops should not be 50% on one core regardless, unless it's underclocked to 1MHz. 🙂