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: Xl.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 20 Nov 2014 20:27:02 -0600 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Thu, 20 Nov 2014 21:27:06 -0500 Organization: IISS Elusive Unicorn Message-ID: <9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> 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> <87a93l35dm.fsf@debian.uxu> X-Newsreader: Forte Agent 6.00/32.1186 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.79.220.227 X-Trace: sv3-RNm3+kFZovnYNGNZFpAXIuPYcuyO0i1aI9ZJ6Ounzsc6SZArAPyOxXzsYPSbOnOXj4LsSPcs7iGrg3+!VXJl3exJ9qv/8uUf/obwykIcCqTTPcY4G0XUg/wEgEcxBgq+/8r1RTBI4ug0INF23bT3n0K3V49a!Rw024HB7/Y2DK4+eOoQcUnLdj6pY X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3654 Xref: number.nntp.giganews.com comp.lang.ada:190898 Date: 2014-11-20T21:27:06-05:00 List-Id: On Thu, 20 Nov 2014 22:54:13 +0100, Emanuel Berg declaimed the following: > >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. > 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. >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. The clock says, say, every 1000 "ticks" is 1microsec... So, after 1000000 "ticks" your millisec delay expires. Without an external timebase (frequency standard) it doesn't matter if your processor counts 1000000 ticks in one millisec or 10 seconds -- if the system has been programmed to assume 1000 ticks is a microsecond, that is what it will increment. >3. I execute the C++ program, and get the trace, which > I get the stats from with the Lisp program. > And what do C++ and Lisp have to do with Ada (since I'm reading this in comp.lang.ada). >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? To interpret the numbers you first have to define what you are measuring. 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... -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/