The way timing sources are currently defined they support both time-based and event-based implementations. As a result, they return ticks and not time. There also isn't a method to capture when execution has completed within one iteration. Therefore there is no way for us to actually calculate if the loop finished late.
We can calculate if the loop started late, and that is what the code attempts to do now, but that isn't what late execution typically means (most would instead think of 'finished late').
As a workaround, the execution time is being calculated properly and can be used to calculate late execution manually.
This can be improved quickly by renaming 'Late' to 'Started Late' or by instead calculating 'missed' iterations. Longer term, we could add new methods to the timing source API to capture the end of an iteration and properly calculate 'Finished Late'.
Beazurt
commented
7 years ago
The way timing sources are currently defined they support both time-based and event-based implementations. As a result, they return ticks and not time. There also isn't a method to capture when execution has completed within one iteration. Therefore there is no way for us to actually calculate if the loop finished late.
We can calculate if the loop started late, and that is what the code attempts to do now, but that isn't what late execution typically means (most would instead think of 'finished late').
As a workaround, the execution time is being calculated properly and can be used to calculate late execution manually.
This can be improved quickly by renaming 'Late' to 'Started Late' or by instead calculating 'missed' iterations. Longer term, we could add new methods to the timing source API to capture the end of an iteration and properly calculate 'Finished Late'.