Re: how to analyze clock drift

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 20 Nov 2014 21:41:41 +0100, Emanuel Berg wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
> writes:
> 
>> Yes, that is when you already know the expected
>> time. I assumed that the reference clock and the
>> clock used in wait are different clocks, deviating
>> at constant speed.
> 
> Yes, I should have told you.

Then, as others already pointed out, it is NOT clock drift. For clocks to
drift you need two independent time sources.

> The data I posted
> yesterday from the Lisp program - the first trace are
> the measured tick times in nanoseconds, and the
> intended tick is *1 ms*.

You should check the clock resolution. Though the clock precision might be
1ns it does not mean that the resolution is. Depending on the time source
it could be some multiplier of the front bus frequency (a few nanoseconds)
or 1s in the case of BIOS clock. Clock resolution is measured when you read
clock in a sequence of calls and compare results. Clocks derived from
real-time counters like TSC will give a new value on each call. Clocks
derived from poor-quality sources will give a sequence of same values and
then jump to a next value. This jump is roughly the clock resolution. Note
that clocks with lesser resolution might be more accurate than
higher-resolution clocks. It is not that simple.

Regarding 1ms, it is not always possible to wait for 1ms. E.g. under
Windows XP you cannot wait shorter than for 10ms, unless you change system
settings. If you see a saw pattern it is an indicator that 1ms is too short
for your OS. And this has nothing to do with the clock quality. It is the
quality of the waitable timer, which is only remotely related to the clock.

> The outputs are by doing the suggested:
> 
>     offset = time1 - time2 - DESIRED_TICK
> 
> (I wonder if I made a mistake here - I assume I should
> put DESIRED_TICK in nanos as well? - and I don't
> remember doing that.)

Of course everything must be in the same time unit.

> Anyway if this method is good, can I make any
> conclusions from the data? For example, how big a mean
> would be considered a big drift,

There is no drift, so long the time source is same.

> how big a deviation an uneven drift, and so on?

You should eliminate a possibility of systematic errors first. See above.

What you actually have measured is certainly not the clock drift or jitter.
You cannot measure them without an independent time source (another clock).
Clock drift and jitter are relative terms.

> Here is the original data again:
> 
> For these clock ticks (in nanoseconds):
> 
>     85033108461718
>     85033109544537
>     85033110621490
>     85033111714366
>     85033112794112
>     85033113871903
>     85033114934049
>     85033116009605
>     85033117089909
>     85033118169656
>     85033119256945
>     85033120336411
>     ...
> 
> The output is:
> 
>     readings: 543
>     mean: 1076366.000000
>     variance: 14127140.000000
>     standard deviation: 3758.608785
>     min: 1062145
>     max: 1096507
> 
>     1082818
>     1076952
>     1092875
>     1079745
>     1077790
>     1062145
>     1075555
>     1080303
>     1079746
>     1087288
>     1079465
>     1072762
>     ...

This is not bad for a waitable timer. Which is what you actually measured.

BTW, typically such timer measurements are made once without load (e.g. you
set the test program at the highest priority) and once under stress load
(e.g. you run a background CPU time consuming process or a heavy duty I/O
process). For timers it is important to work reliable under time-sharing
load.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de