Re: how to analyze clock drift

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
writes:

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

I use Debian:

    Linux debian 3.17.1 #9 SMP Fri Nov 7 23:05:01 CET
    2014 x86_64 GNU/Linux

On this CPU:

    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                2
    On-line CPU(s) list:   0,1
    Thread(s) per core:    1
    Core(s) per socket:    2
    Socket(s):             1
    NUMA node(s):          1
    Vendor ID:             AuthenticAMD
    CPU family:            15
    Model:                 35
    Model name:            AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
    Stepping:              2
    CPU MHz:               1000.000
    CPU max MHz:           2000.0000
    CPU min MHz:           1000.0000
    BogoMIPS:              1989.92
    L1d cache:             64K
    L1i cache:             64K
    L2 cache:              512K
    NUMA node0 CPU(s):     0,1

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

No, I mean, the deviation isn't constant, the period
is *supposed* to be constant, but it isn't, that's the
whole thing - it isn't, and to what degree and with
what characteristics? That's what I want to examine.

The program is a hierarchical scheduler. It has a
global period which you can specify (in ms). For the
trace I showed you, the period is 1 ms, and the
readings are in nanos. The trace are the measured,
actual times.

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
   - interrupt at every tick, and output the actual
   time - with the C++ <chrono> stuff.

3. I execute the C++ program, and get the trace, which
   I get the stats from with the Lisp program.

4. Now I want to understand the stats (what they
   express, because I understand how to compute them
   assuming the Lisp program is correct).

> Of course everything must be in the same time unit.
> ...
> This is not bad ... for a waitable timer. Which is
> what you actually measured.

That data isn't correct, I forgot to turn the desired
tick from millis to nanos, I'll fix that and post the
correct data here in a minute.

-- 
underground experts united