Re: Delayed response for sleep function

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2022-06-21 09:35:12

#include <chrono>
#include <concepts>
#include <iostream>
#include <iomanip>
#include <ratio>
#include <unistd.h>

int
main()
{
    using clock_type = std::chrono::high_resolution_clock;
    using namespace std::literals;

    auto t = clock_type::now();
    auto const t0 = t;
    auto const t1 = t0 + 1s;
    while(t < t1)
    {
        ::usleep(1);
        t = clock_type::now();
    }

    std::cout
        << std::chrono::duration_cast<std::chrono::duration<double,
std::milli>>(t - t0).count()
        << "ms\n";
}

Example output:

Program returned: 0
1000.47ms

https://godbolt.org/z/bcGPcebP1

On Tue, 21 Jun 2022 at 10:12, Neil Groves via Boost <boost_at_[hidden]>
wrote:

> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>