Re: Delayed response for sleep function

From: Neil Groves (neilgroves_at_[hidden])
Date: 2022-06-21 08:12:32

On Tue, 21 Jun 2022 at 04:08, William Linkmeyer via Boost <
boost_at_[hidden]> 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