You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our logs have a time field that reports the number of milliseconds since we started scheduling the block. This is good, but most blocks take 0ms or 1ms, which means that sums based on these 0ms blocks are problematic (e.g. it could be that it just always take 0.9ms, so with 100,000 such blocks, that would actually be 90 seconds, which is significant). We should increase the precision of this time field either to microseconds or nanoseconds.
The approach of doing this by modifying Utilities::GetProcessorTime() to return nanoseconds is problematic, because that messes with our time limits. Instead, I think this would be most easily implemented by modifying the logging code to compute its own more precise elapsed time instead of using Utilities::GetProcessorTime().
Summary:
Decide ns or us.
Update the event logger in logger.cpp to print the time with the higher precision.
Update scripts to account for this timing being in a higher precision. They would work, but they would think everything took 10^6 or 10^3 times longer than it did.
The text was updated successfully, but these errors were encountered:
I recommend microseconds. We are not down to nanosecond precision in our performance. However, it might be prudent to make the time field something like time_us instead; this might make it easier to migrate to nanoseconds in the future if necessary, as it will shine a bright light on scripts which still need to be updated.
Our logs have a
time
field that reports the number of milliseconds since we started scheduling the block. This is good, but most blocks take 0ms or 1ms, which means that sums based on these 0ms blocks are problematic (e.g. it could be that it just always take 0.9ms, so with 100,000 such blocks, that would actually be 90 seconds, which is significant). We should increase the precision of thistime
field either to microseconds or nanoseconds.The approach of doing this by modifying
Utilities::GetProcessorTime()
to return nanoseconds is problematic, because that messes with our time limits. Instead, I think this would be most easily implemented by modifying the logging code to compute its own more precise elapsed time instead of usingUtilities::GetProcessorTime()
.Summary:
The text was updated successfully, but these errors were encountered: