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: Fri, 21 Nov 2014 10:48:59 -0600 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Fri, 21 Nov 2014 11:49:05 -0500 Organization: IISS Elusive Unicorn Message-ID: <3apu6ap126abi6oalch9vpre20hjij2uon@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> <9t7t6al8bmifd9krh6koiegttgsvcovadg@4ax.com> <87d28h1cj9.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.68.179.121 X-Trace: sv3-ephfzJYf4OkUqtdBFhQVWq7o7F5y2CeTYJQ8m6MFPnKEpCYSW2FUhIzNJ0jPqlxg/sEso/jR2AhJHH0!cbIQRyUdOEm4E58I1AapiGW3EFrl1kzytBCpUt3IPPpwgjJLnUS7c82MU48oS+eMsNa1DmUpxebV!xXgBAdivC4yOprl5WKro4Al5iDmR 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: 8079 Xref: number.nntp.giganews.com comp.lang.ada:190913 Date: 2014-11-21T11:49:05-05:00 List-Id: On Fri, 21 Nov 2014 04:02:34 +0100, Emanuel Berg declaimed the following: > >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. > It is not drift as most of the industry would define it. > >"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. > Nothing in your test, as described, can be used to confirm that "target" statement, as nothing in your description is measuring the rate of the clock itself. If your system suddenly changed the clock speed without making changes in the ticks-per-second value, your program would still report "1ms" but those would take place at 2ms real intervals. To measure actual clock variation you MUST have an independent time-base for comparison. > >I'm measuring how the logged times differs from an >imaginary perfect log that would look: > >1000000 >2000000 >3000000 >... > >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. > Which still comes down to "what are you measuring". You are NOT measuring real clock "drift" since you do not have reliable time base standard with which to determining the system reported times. The ONLY conclusion /I/ could draw from this experiment is that you are measuring the OS LATENCY between the expiration of a delay statement and the reading of the clock counter. If you know the system ticks-per-second of the clock I could put the conclusion on firmer footing (eg: the latency between delay statement expiration to reading of the clock value is NNN clock ticks +/- mmm ticks){since you don't have an external measurement on your clock, times reported are all relative to clock ticks passing; a slow clock still reports the same number of ticks as a fast clock} Try it: change your delay from a nominal 1msec to, say 50msec. Rerun the experiment. I'd expect your differences to still be very similar the numbers you obtained at 1msec -- ie; the differences are in the latency between delay and read operations, independent of timer rate itself. Actually... Also try using a delay of 0.0 -- that should be recording only the latency between a delay statement that immediately returns and the reading of the clock value. If the clock is slow enough, you'll likely get a delta of 0s with the occasional 1 when the clock updates. While this (http://msdn.microsoft.com/en-us/library/windows/hardware/jj602805%28v=vs.85%29.aspx) is discussing Windows, this paragraph may be of interest: """ The system time is updated on every tick of the system clock, and is accurate only to the latest tick. If the caller specifies an absolute expiration time, the expiration of the timer is detected during processing of the first system clock tick that occurs after the specified time. Thus, the timer can expire as much as one system clock period later than the specified absolute expiration time. If a timer interval, or relative expiration time, is instead specified, the expiration can occur up to a period earlier than or a period later than the specified time, depending on where exactly the start and end times of this interval fall between system clock ticks. Regardless of whether an absolute or a relative time is specified, the timer expiration might not be detected until even later if interrupt processing for the system clock is delayed by interrupt processing for other devices. """ >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. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/