Closed davidhjp01 closed 3 months ago
@kyllingstad Two things I updated:
1. Using
std::is_same
to check if cosim::time_point::period
and Time::time_point::period
are the same type. If that is the case skipping duration_cast
.3. Using int
for sampling_period_to_monitor
.
I found that using duration
type for sampling_period_to_monitor
slows down the simulation quite a bit on my use-case (small step sizes) because seems the duration
instance needs to be copied on every step (via load
) for the hash computation. So I would like to keep it as int
type indicating millisecond for now.
Also additional duration_cast
was quite an overhead. So trying to check the types are equal (e.g. nano) and if that is the case skipping duration_cast
(this assumes the standard uses the same period type for the returning value when all time_point
s in the expression also has the same period
type?).
Seems the problem was due to my local PC. Will try the original suggestion.
When the simulation step size is too small, e.g. 0.001, a fixed
cosim::real_time_config.steps_to_monitor
value would not be sufficient to compute the rolling average real time factor because of the following scenario:steps_to_monitor
to a large value (1000) because the default 5 is too small window size to accurately compute RTF.To avoid this problem,
cosim::real_time_config.sampling_period_to_monitor
is introduced. It sets a sampling period in second(s) used in the rolling average real time factor calculation. When the value is greater than zero, the real time factor is computed periodically using the specified time instead of thesteps_to_monitor
value.