RT Box Processor Load for Enabled Subsystem

Question

Hi,

I am currently working with a RT Box 1. Since the model is quite large, respectively the discretization step size quite small, the RT Box' processor load is almost at 100%.

Now I have added a C-Script which calibrates my measurement. This C-Script is only doing something for one second at the very beginning. However, the processor load is rising to 120% constantly (but not running into an error?!). For this reason, I tried to use an Enabled Subsystem. After 1s the processor load descends visibly to 110%, which is still approx. 10% more than without these extra blocks. For my understanding this should be similar since the Subsystem is disabled. Am I missing something?

Is there a better solution to stop evaluating code in order to reduce processor load?

Btw, the RT Box never runs into an overflow even when running at 120%?! And the discretization step size could probably be reduced, however, I would prefer to run it this fast at least for my first tests.

I have added a test model with a way too small discretization step size to make the problem better visible.

Thank you for your help and best regards,

Reto

Answer 1

> After 1s the processor load descends visibly to 110%, which is still approx. 10% more than without these extra blocks. For my understanding this should be similar since the Subsystem is disabled. Am I missing something?

While the code within the block does not execute when the system is not enabled, there still is some computational overhead for introducing the Enabled Subsystem.  If the C-Script was more complex one would expect a more significant difference between placing the C-Script in an Enabled Subsystem vs. the conventional implementation.

> Is there a better solution to stop evaluating code in order to reduce processor load?

The Enabled Subsystem is a good approach in this instance. 

You should take a holistic approach to improving your model execution - e.g. simplifying the model if possible, removing unnecessary scopes/displays, and harmonizing sample times. There also is the RT Box model optimization tutorial on our website which might be helpful to review the basics.

Regarding sample times, one very minor opportunity in this case is to change the Delay block's Sample Time parameter from 1 second to Ts. With that change an internal counter is not need to ensure the event happens every 1s, but every loop.  You can always do a diff between the C code generated from two models to see the impact.

The improvement again depends on the complexity of the task vs. the overhead to ensure it only happens periodically. It also depends on what percentage that particular portion of the model contributes to the overall processor load.

> Btw, the RT Box never runs into an overflow even when running at 120%?!

The reported value is the peak processor load over several time steps, and therefore can exceed 100%.  The processor load will vary from time-step to time-step based on the model and/or the RT Box hardware/firmware effects. The RT Box will halt on error only following several consecutive overruns based on the Overrun Limit specified in the Coder Options window.

Note that when the overrun occurs the RT Box outputs are not updated at the end of the time-step. Additional latency and potentially integration errors are introduced in the loop, so running at over 100% is probably not recommended.

Comments

Hi Bryan,
thank you again for your competent answer. Good to know that using an Enable Subsystem is the correct way.

> While the code within the block does not execute when the system is not enabled, there still is some computational overhead for introducing the Enabled Subsystem.  If the C-Script was more complex one would expect a more significant difference between placing the C-Script in an Enabled Subsystem vs. the conventional implementation. ​

I can understand that there is an overhead, but something like 10% seemed quite high. But as you mentioned later, running over 100% maybe isn't the best idea. Therefore, I deleted some stuff from my model in order to get lower usage. I got now following processor loads:
- Enabled Subsystem: 37%
- Disabled Subsystem: 34%
- Without Subsystem: 31%

So the overhead seems to be approx.. 3% and much less than 10%. This is acceptable, but it can still hurt as my model was running before stable at 98-99% CPU load.

> You should take a holistic approach to improving your model execution - e.g. simplifying the model if possible, removing unnecessary scopes/displays, and harmonizing sample times. There also is the RT Box model optimization tutorial on our website which might be helpful to review the basics.

Totally agree with you. But if you are working on a prototype and you don't know exactly what is happening within the model, scopes and displays help a lot. And also receiving a lot of measurements sometimes helps. At the end, the final model will probably less demanding.

> Regarding sample times, one very minor opportunity in this case is to change the Delay block's Sample Time parameter from 1 second to Ts. With that change an internal counter is not need to ensure the event happens every 1s, but every loop.  You can always do a diff between the C code generated from two models to see the impact.

This was a typo in my test model. In my real model I am using Ts as you mentioned.

 > Note that when the overrun occurs the RT Box outputs are not updated at the end of the time-step. Additional latency and potentially integration errors are introduced in the loop, so running at over 100% is probably not recommended.

What exactly happens if the model without External Mode active is below 100% and if activated rises over 100%? Are the HW values updated correctly and the plotted values might be slightly off or is this undefined?

Thank you for your help and best regards,

Reto

---

Great feedback and good points, thanks Reto.

One other point regarding holistic optimization is the Model Settings blocks are useful to gain marginal advantage in processing time.  This is more relevant in HIL applications opposed to RCP.

> What exactly happens if the model without External Mode active is below 100% and if activated rises over 100%? Are the HW values updated correctly and the plotted values might be slightly off or is this undefined?

The exact hardware behavior will depend based on the RT Box hardware, firmware version, and code generation settings.  There is no one answer in this case and is subject to change.

Regarding the PLECS Scope, there will be no indication that a given step actually took two time steps. The trace will be plotted as if the step had occurred at the correct time.  Again there will also be some numerical integration error as the plant was discretized at Ts but the calculation took 2*Ts.

---

Thanky you again for these good anwsers.

I will definitely look into reducing my model.

Best regards,

Reto

Answer 2

Try reducing the execution step of BOX?