From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: Emanuel Berg <embe8573@student.uu.se>
Newsgroups: comp.lang.ada
Subject: Re: how to analyze clock drift
Date: Fri, 21 Nov 2014 23:31:13 +0100
Organization: Aioe.org NNTP Server
Message-ID: <8761e8i3ta.fsf@debian.uxu>
References: <6uun6alsp3jh1pob6g9qgcg85etqgenmd0@4ax.com>
	<m4h061$oct$1@speranza.aioe.org> <87zjbn3nss.fsf@debian.uxu>
	<1nvfhit2csxr5.41v36jksch28$.dlg@40tude.net> <87k32qet5y.fsf@debian.uxu>
	<188uppnlnvqgq$.1kjz3jnhjxqji.dlg@40tude.net> <87fvdd38qi.fsf@debian.uxu>
	<evnp6z0i9v6g.5vwpfkn0jzek$.dlg@40tude.net> <87a93l35dm.fsf@debian.uxu>
	<9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> <87d28h1cj9.fsf@debian.uxu>
	<3apu6ap126abi6oalch9vpre20hjij2uon@4ax.com> <87egswi7bw.fsf@debian.uxu>
NNTP-Posting-Host: feB02bRejf23rfBm51Mt7Q.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain
X-Complaints-To: abuse@aioe.org
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
X-Notice: Filtered by postfilter v. 0.8.2
Cancel-Lock: sha1:K4rMnK8v+dj4Incx3H34zSr2nf0=
Mail-Copies-To: never
Xref: news.eternal-september.org comp.lang.ada:23620
Date: 2014-11-21T23:31:13+01:00
List-Id: <comp.lang.ada>

Emanuel Berg <embe8573@student.uu.se> writes:

> Is that considered reliable to the point it makes
> sense diagnosing sleep_until with that instead of
> the C++'s now()?

On the other hand, isn't that from where now() gets
its data?

I have checked the following docs:

    http://en.cppreference.com/w/cpp/chrono/system_clock/now
    http://en.cppreference.com/w/cpp/thread/sleep_until

For sleep_until, they say:

    The clock tied to sleep_time is used, which means
    that adjustments of the clock are taken into
    account. Thus, the duration of the block might,
    but might not, be less or more than sleep_time -
    Clock::now() at the time of the call, depending on
    the direction of the adjustment. The function also
    may block for longer than until after sleep_time
    has been reached due to scheduling or resource
    contention delays.

But for now(), they don't say one word it should be
unreliable so it should be enough to diagnose
sleep_until.

-- 
underground experts united