Sampling period for computing the rolling average real time factor

[davidhjp01]

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:

1. Set steps_to_monitor to a large value (1000) because the default 5 is too small window size to accurately compute RTF.
2. Set the simulation step size to 0.001. The solution is good enough when the simulation can keep RTF 1.
3. When RTF drops, for ex. to 0.01, during the simulation for some reason, user would only see the updated RTF after 100 seconds.

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 the steps_to_monitor value.

[kyllingstad]

elapsedSimTime and elapsedRealTime are two different std::chrono::duration types associated with different clocks. The former is associated with Time, which is an alias for std::chrono::steady_clock and represents real time, while the latter is associated with cosim::detail::clock, which is a clock defined to represent simulation time. Therefore, it might be fragile to use their count() values like this, because it assumes that their tick period is the same.

Two options:

1. Insert std::duration_cast calls and cast them to a common type with the same tick period.
2. Insert a compile-time check like static_assert(decltype(elapsedSimTime)::period == decltype(elapsedRealTime)::period);

I think I prefer the first one if it works, but there may be arguments in favour of the latter too.

[kyllingstad]

I see now that this is old code moved from elsewhere in the file. But then this is a good opportunity to fix it. ;)

[davidhjp01]

Added duration_cast as well as in update_rolling_average_real_time_factor.

[davidhjp01]

After adding duration_cast (or some other updates), I see noticeable performance drops. Investigating on it..

The issue was due to my laptop, updated as suggested.

[davidhjp01]

@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_points in the expression also has the same period type?).

Seems the problem was due to my local PC. Will try the original suggestion.

[kyllingstad]

Looks good!