Re: how to analyze clock drift

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

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

> Without a separate clock, it is not /drift/... It is
> OS latency in the process of reading the clock after
> the delay expires... And that latency is going to
> vary by how many other processes are running at the
> same or higher priority.
>
> Delay expires, task is put at the end of its
> priority queue, and you only get to /read/ the clock
> value when the OS gives your task its quantum of
> time.

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.

>> Here is how it works:
>>
>> 1. I specify the global period to 1 ms.
>>
>> 2. In the C++ program, at every tick (supposedly
>>    every 1 ms) I log the actual time. I do both those
>>    things
>
> Define "actual time" -- if that actual time is
> coming from the same clock, the clock drift is
> masked.

"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.

>> 4. Now I want to understand the stats (what they
>> express, because I understand how to compute them
>> assuming the Lisp program is correct).
>
> Isn't that basically your assignment?

Well. Have have a 39 page report at this point. This
is a short section but the report is made up of short
sections, for sure.

> To interpret the numbers you first have to define
> what you are measuring.

I'm measuring how the logged times differs from an
imaginary perfect log that would look:

1000000
2000000
3000000
...

> If there is a "sawtooth", running an autocorrelation
> function over the data might indicate the period.
> Then it becomes a task to explain such a period --
> perhaps the OS resolution is some fraction of your
> desired value, and what you are seeing is an
> accumulating error until the next multiple...

No, I'm not going to do that. I'm only going to show
the data and what the data means. What is lacking is
some sort of conclusion, because the stats don't
really tell if you don't know what is normal - is it
bad, good, and how would that show (i.e., could that
be computed, as well - perhaps as a function of all
values...), stuff like that.

Here is what I've written so far. Feel free to suggest
improvements. I'll paste the LaTeX source, I think you
can read it just the same:

\subsection{the C++ and Linux timers}

To uphold an even rate of periodic scheduling, the C++
library function $std::this\_thread::sleep\_until$ is
used. However, on

\url{http://en.cppreference.com/w/cpp/thread/sleep_until}

they mention that $sleep\_until$ may actually ``block
for longer [than what has been specified] due to
scheduling or resource contention delays''.

To get a grip on how jittery the global tick is, $-l$
(or equivalently $--log$) can be used to have the
hierarchical scheduler output the current time (in
nanoseconds), at every tick, again, according to the
\texttt{<chrono>} library functions.

Here is a sample output for a period of one
millisecond:

\begin{verbatim}

    85033684319264
    85033685397613
    85033686471213
    85033687542299
    85033688624839
    85033689696763
    85033690770643
    85033691846478
    85033692929297
    ...

\end{verbatim}

The following method is then used to calculate the
offsets from the intended tick times:

\begin{verbatim}

  offset_0 = time_1 - time_0 - DESIRED_TICK
  offset_1 = time_2 - time_1 - DESIRED_TICK
  ...

\end{verbatim}

This produced, for this example run:

\begin{verbatim}

  82819
  76953
  92876
  79746
  77791
  62146
  75556
  80304
  79747
  ...

\end{verbatim}

Last, for all 543 offsets acquired in this example
computation, the following statistical data were
acquired:

\begin{verbatim}

    readings:            543
    mean:                76367.000000
    variance:            14127140.000000
    standard deviation:  3758.608785
    min:                 62146
    max:                 96508

\end{verbatim}

The mean value is a measure of the size of the drift.
The minimum and maximum values are the worst-case
behaviors for this particular run: they are the
smallest and biggest distances observed off the
intended tick time. The standard deviation is a
measure of the stability of the drift.

-- 
underground experts united