Drift from system time about quanta HOT 1 OPEN

Apologies for the delay in response here. I saw this issue when you filed it, immediately looked it over, did some calculations, and then.... forgot to respond. 😭

It does indeed appear like there is potentially a calibration issue here, or that we're simply hitting the limits of what the calibration loop can provide. Calibration cannot cope with changes to system time through mechanisms like NTP, which may skew time forwards or backwards at a rate faster or slower than the actual local passage of time.

All of that said, I'd say your test case is reasonable. Running it locally, I can observe the same slow drift over time, in which the degree that it drifts changes between runs. I had also observed a few runs where the drift was sinusoidal, likely related to legitimate NTP adjustment/tracking.

Replacing quanta with simple calls to Instant::now all but eliminates the drift, locking it tightly to a few hundred nanoseconds plus or minus over the course of a few minutes. This is not surprising, as Instant::now is based on CLOCK_MONOTONIC for unix-y platforms, where it will be subject to NTP adjustments (but simply ensured to at least only change monotonically), and so is likely to stay much closer to SystemTime which is similarly disciplined by NTP.

This definitely has me thinking about re-examining the use of TSC overall, but I would suggest just utilizing SystemTime/Instant for the time being since that should be accurate enough if you have a strict need to present a timestamp that is wall clock-referenced.

from quanta.