#include <chrono>
#include <concepts>
#include <iostream>
#include <iomanip>
#include <ratio>
#include
On Tue, 21 Jun 2022 at 04:08, William Linkmeyer via Boost < boost@lists.boost.org> wrote:
I was under the impression that drift compensation is often hardware supported and extremely accurate (at least for the RTCs I’ve worked on).
Most clock implementations are drift compensated either with NTP or PTP on most desktop platforms. You have a systematic delay in responding to the clock reaching the target time. Thus it is systematically late by an unknown amount in the case of a typical OS. This is normally sufficient. One can dynamically adjust the sleep interval to continuously converge to the target, at the expense of sometimes having too early responses. This dynamic adjustment can be a simple correction based on the latest sample or smoothed with an Exponential Moving Average. Alternatively you set the sleep to be less than your target by an amount and finish by spinning. This will lower jitter at the expense of more CPU usage.
To optimize latency, the spinning solutions need to avoid excessive cache contention. Getting this completely optimal calls for different solutions dependent on the varying data structures being queried. The clock is probably fairly reasonable to spin on. Most platforms have the implementation extremely efficient. To take it one step further on many processors you can finish the spin with the timestamp counter; if your processors are invariant_tsc. It is necessary to get the calibration for this on many machines, but not all. TSC can drift versus system clock partly because of the resynchronization that happens with PTP/NTP. I have often used a type like a HiResClock which uses system_clock but also uses TSC with periodic correction to the coefficient required to map the clocks to time. This is a solution for a non-steady clock. For other cases where you are measuring intervals it is vital to avoid the resynchronization effects as it may resynchronize part of the way through your interval being measured. This is why we also have a steady_clock in the standard. To combine the real-time clock with the steady_clock is often disappointing since it brings back the non-steady problems through the resynchronization procedure.
WL
I hope this is helpful.
Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost