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: border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Fri, 21 Nov 2014 04:02:34 +0100 Organization: Aioe.org NNTP Server Message-ID: <87d28h1cj9.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> <87a93l35dm.fsf@debian.uxu> <9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> 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:38nmEtUBe+VcksJsPC0KedT8flQ= Mail-Copies-To: never Xref: number.nntp.giganews.com comp.lang.ada:190900 Date: 2014-11-21T04:02:34+01:00 List-Id: Dennis Lee Bieber writes: > 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. I am aware there are many factors why this is as it is, including the OS, what configurations of other processes (and their nature) that runs in parallel, scheduling and priorities, and so on almost indefinitely, however I'm not analyzing those factors here, I'm only analyzing how the outputted data differs from the ideal, perfect time, which is defined (here) as a tick every millisecond. The "drift" mentioned is the drift from that perfect 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. "Actual time" is defined, in the usage above, as: the time in nanoseconds that the C++ outputs every global tick, which is programmed to occur every millisecond but doesn't keep to that, in ways that are the target of the inquiry. >> 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? Well. Have have a 39 page report at this point. This is a short section but the report is made up of short sections, for sure. > To interpret the numbers you first have to define > what you are measuring. I'm measuring how the logged times differs from an imaginary perfect log that would look: 1000000 2000000 3000000 ... > 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... No, I'm not going to do that. I'm only going to show the data and what the data means. What is lacking is some sort of conclusion, because the stats don't really tell if you don't know what is normal - is it bad, good, and how would that show (i.e., could that be computed, as well - perhaps as a function of all values...), stuff like that. Here is what I've written so far. Feel free to suggest improvements. I'll paste the LaTeX source, I think you can read it just the same: \subsection{the C++ and Linux timers} To uphold an even rate of periodic scheduling, the C++ library function $std::this\_thread::sleep\_until$ is used. However, on \url{http://en.cppreference.com/w/cpp/thread/sleep_until} they mention that $sleep\_until$ may actually ``block for longer [than what has been specified] due to scheduling or resource contention delays''. To get a grip on how jittery the global tick is, $-l$ (or equivalently $--log$) can be used to have the hierarchical scheduler output the current time (in nanoseconds), at every tick, again, according to the \texttt{} library functions. Here is a sample output for a period of one millisecond: \begin{verbatim} 85033684319264 85033685397613 85033686471213 85033687542299 85033688624839 85033689696763 85033690770643 85033691846478 85033692929297 ... \end{verbatim} The following method is then used to calculate the offsets from the intended tick times: \begin{verbatim} offset_0 = time_1 - time_0 - DESIRED_TICK offset_1 = time_2 - time_1 - DESIRED_TICK ... \end{verbatim} This produced, for this example run: \begin{verbatim} 82819 76953 92876 79746 77791 62146 75556 80304 79747 ... \end{verbatim} Last, for all 543 offsets acquired in this example computation, the following statistical data were acquired: \begin{verbatim} readings: 543 mean: 76367.000000 variance: 14127140.000000 standard deviation: 3758.608785 min: 62146 max: 96508 \end{verbatim} The mean value is a measure of the size of the drift. The minimum and maximum values are the worst-case behaviors for this particular run: they are the smallest and biggest distances observed off the intended tick time. The standard deviation is a measure of the stability of the drift. -- underground experts united