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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Thu, 20 Nov 2014 22:54:13 +0100 Organization: Aioe.org NNTP Server Message-ID: <87a93l35dm.fsf@debian.uxu> 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> NNTP-Posting-Host: feB02bRejf23rfBm51Mt7Q.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:5DzD5/LOaL3uGn22KAhmD72lU68= Mail-Copies-To: never Xref: news.eternal-september.org comp.lang.ada:23584 Date: 2014-11-20T22:54:13+01:00 List-Id: "Dmitry A. Kazakov" 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++ 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