Re: how to analyze clock drift

[Emanuel Berg <embe8573@student.uu.se>]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

>> I am aware there are many factors why this is as it
>> is, including the OS, what configurations of other
>> processes (and their nature) that runs in parallel,
>> scheduling and priorities, and so on almost
>> indefinitely, however I'm not analyzing those
>> factors here, I'm only analyzing how the outputted
>> data differs from the ideal, perfect time, which is
>> defined (here) as a tick every millisecond. The
>> "drift" mentioned is the drift from that perfect
>> time.
>>
> It is not drift as most of the industry would
> define it.

OK. I'll CC this to my teacher (including the full
quotes of your message) and see what he says.

Intuitively, I think it is clear: time is perfect but
the clock isn't, it is a close but never perfect
estimate of time, and if there is a drift away (which
of course it'll always be, otherwise you could just
reset the clock if it was "correctly" off by some
constant margin), i.e., with a drift, with time, the
clock will be even worse (i.e., further away from
time).

>> "Actual time" is defined, in the usage above, as:
>> the time in nanoseconds that the C++ outputs every
>> global tick, which is programmed to occur every
>> millisecond but doesn't keep to that, in ways that
>> are the target of the inquiry.
>
> Nothing in your test, as described, can be used to
> confirm that "target" statement, as nothing in your
> description is measuring the rate of the clock
> itself.
>
> If your system suddenly changed the clock speed
> without making changes in the ticks-per-second
> value, your program would still report "1ms" but
> those would take place at 2ms real intervals.
>
> To measure actual clock variation you MUST have an
> independent time-base for comparison.

Are you saying:

1. we know that sleep_until isn't perfect - it can
   sleep longer than x, for an argument x, as the docs
   say

2. I am attempting to log the error of sleep_until
   with now() but that can't be done as now() uses the
   same technology and thus can likewise be incorrect

*Or*, are you saying:

we can't trust now() *at all* because it invokes an OS
routine which can give it whatever data?

If you are saying the second, I think it is assumed
that the system time is an adequate measure of
physical (perfect) time. So the ideal time I describe
above is assumed to be what is outputted by now, and
that is assumed to be a adequately correct reading of
how much the delay (sleep_until) actually sleep, i.e.
its drift from the desired perfect periodicity.
(Again, I'm CC-ing this to my teacher, hopefully he'll
mail me and I'll get back on this, anyway this is how
I always assumed the situation so this discussion is
really great if it helps to remove a
misunderstanding.)

> Which still comes down to "what are you measuring".
> You are NOT measuring real clock "drift" since you do
> not have reliable time base standard with which to
> determining the system reported times.

Yes, now I understand what you mean. I think it is
agreed that time is good enough for the purposes of
this project. This isn't about examining the lack of
quality of the <chrono> stuff in general, it is about
specifically logging the "over-delay" of sleep_until
which now() is deemed capable of.

> The ONLY conclusion /I/ could draw from this
> experiment is that you are measuring the OS LATENCY
> between the expiration of a delay statement and the
> reading of the clock counter. If you know the system
> ticks-per-second of the clock I could put the
> conclusion on firmer footing (eg: the latency
> between delay statement expiration to reading of the
> clock value is NNN clock ticks +/- mmm ticks){since
> you don't have an external measurement on your
> clock, times reported are all relative to clock
> ticks passing; a slow clock still reports the same
> number of ticks as a fast clock}
>
> Try it: change your delay from a nominal 1msec to,
> say 50msec. Rerun the experiment. I'd expect your
> differences to still be very similar the numbers you
> obtained at 1msec -- ie; the differences are in the
> latency between delay and read operations,
> independent of timer rate itself.
>
> Actually... Also try using a delay of 0.0 -- that
> should be recording only the latency between a delay
> statement that immediately returns and the reading
> of the clock value. If the clock is slow enough,
> you'll likely get a delta of 0s with the occasional
> 1 when the clock updates.
>
> While this
> (http://msdn.microsoft.com/en-us/library/windows/hardware/jj602805%28v=vs.85%29.aspx)
> is discussing Windows, this paragraph may be of
> interest:
>
> """ The system time is updated on every tick of the
> system clock, and is accurate only to the latest
> tick. If the caller specifies an absolute expiration
> time, the expiration of the timer is detected during
> processing of the first system clock tick that
> occurs after the specified time. Thus, the timer can
> expire as much as one system clock period later than
> the specified absolute expiration time. If a timer
> interval, or relative expiration time, is instead
> specified, the expiration can occur up to a period
> earlier than or a period later than the specified
> time, depending on where exactly the start and end
> times of this interval fall between system clock
> ticks. Regardless of whether an absolute or a
> relative time is specified, the timer expiration
> might not be detected until even later if interrupt
> processing for the system clock is delayed by
> interrupt processing for other devices. """

-- 
underground experts united