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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Thu, 20 Nov 2014 22:27:11 +0100 Organization: cbb software GmbH Message-ID: References: <6uun6alsp3jh1pob6g9qgcg85etqgenmd0@4ax.com> <87zjbn3nss.fsf@debian.uxu> <1nvfhit2csxr5.41v36jksch28$.dlg@40tude.net> <87k32qet5y.fsf@debian.uxu> <188uppnlnvqgq$.1kjz3jnhjxqji.dlg@40tude.net> <87fvdd38qi.fsf@debian.uxu> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: wfRpp7ltpEWhI2na6kgpfA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!news.bnb-lp.com!news.glorb.com!aioe.org!.POSTED!not-for-mail Xref: number.nntp.giganews.com comp.lang.ada:190885 Date: 2014-11-20T22:27:11+01:00 List-Id: On Thu, 20 Nov 2014 21:41:41 +0100, Emanuel Berg wrote: > "Dmitry A. Kazakov" > 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