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!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!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: Sat, 22 Nov 2014 12:18:14 -0600 From: Dennis Lee Bieber Newsgroups: comp.lang.ada Subject: Re: how to analyze clock drift Date: Sat, 22 Nov 2014 13:18:20 -0500 Organization: IISS Elusive Unicorn Message-ID: <98h17atrhtl9kitthjf8ukt1f7rk1ribvc@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> <3apu6ap126abi6oalch9vpre20hjij2uon@4ax.com> <87k32oi7r8.fsf@debian.uxu> X-Newsreader: Forte Agent 6.00/32.1186 X-No-Archive: YES MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 108.79.223.115 X-Trace: sv3-mPTtoX5EWAMhQTefDAJo4X4w8ZOwYsUoiv3M2lyxTe8DlLRVqPPnK+F7SY6Bkni/zRg855Z+/tE5ahW!HininMPHJKaHIO14zm6kAMugoWyFKSBnoppwPtQ0L+Ajh+llu4t5PIaCpMVP/GpMLztysjY8uxda!4493NS+Xuz100ekKIOjBZxV6rsa1 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: 7893 X-Received-Bytes: 8005 X-Received-Body-CRC: 3471254076 Xref: news.eternal-september.org comp.lang.ada:23648 Date: 2014-11-22T13:18:20-05:00 List-Id: On Fri, 21 Nov 2014 22:06:03 +0100, Emanuel Berg declaimed the following: > >Are you saying: > >1. we know that sleep_until isn't perfect - it can > sleep longer than x, for an argument x, as the docs > say > >2. I am attempting to log the error of sleep_until > with now() but that can't be done as now() uses the > same technology and thus can likewise be incorrect > >*Or*, are you saying: > >we can't trust now() *at all* because it invokes an OS >routine which can give it whatever data? > All three apply. You can not use the system clock to measure errors in the system clock. Sleep_Until may be off by one system tick (which itself may be a rather large quantity -- 15.6mSec is common in Windows OS, though I believe privileged code can change that); Sleep_Until and Now are both using the same clock, so if the clock ran slow (meaning the sleep runs longer than nominal), Now will report the slow time value -- not the real time that is longer; and Now may be affected by any background updates of the system time (NTP updates, for example). At the least, you need to know the granularity at which "now" is updated, as that is likely to also be the granularity at which sleep_until triggers. System time is determined by some counter (of ticks) divided by some constant representing the expected ticks per second (TPS). Regardless of how the clock is varying, it will report that one second has passed when TPS ticks have been counted. (Worse, the OS ticks are, themselves, based upon some number of hardware clock cycles OR some external clock interrupt -- given that my current systems have a "turbo boost" in which all but one core is halted while the running core gets clocked much faster, having the system tick based on the CPU clock frequency would be hairy) In order to determine clock drift, you must measure how many ticks really took place relative to an external time-base (which is presumed to be "truth" -- eg; a 1 pulse-per-second output from a cesium time-base [atomic clock]). You would read the system clock value each time the external time base pulses some interrupt line (or you use a tight polling loop). You also need to know the system's defined value for TPS. (apologies for another M$ reference -- worse, .NET specific, and the .NET runtime may be doing some other translations from the hardware and OS clock ticks. -- on Windows you could expect to see the clock value update in jumps of 156000 ticks -- unless it internally calls some other counter to get finer resolution) http://msdn.microsoft.com/en-us/library/system.timespan.tickspersecond%28v=vs.110%29.aspx That 15.6mSec would also affect the jitter in your measurements as you could start a delay at either just before an update or just after the update -- that means 15mSec of potential variance. Borrowing from the Python documentation: """ time.clock() On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of “processor time”, depends on that of the C function of the same name, but in any case, this is the function to use for benchmarking Python or timing algorithms. On Windows, this function returns wall-clock seconds elapsed since the first call to this function, as a floating point number, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond. """ """ time.sleep(secs) Suspend execution for the given number of seconds. The argument may be a floating point number to indicate a more precise sleep time. The actual suspension time may be less than that requested because any caught signal will terminate the sleep() following execution of that signal’s catching routine. Also, the suspension time may be longer than requested by an arbitrary amount because of the scheduling of other activity in the system. """ """ time.time() Return the time in seconds since the epoch as a floating point number. Note that even though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second. While this function normally returns non-decreasing values, it can return a lower value than a previous call if the system clock has been set back between the two calls. """ In Python, to do really fine sleeps requires using a busy loop as the system sleep routine is too coarse (especially in Windows) -- and it makes delay-until tricky to implement as time.clock() is not wall-clock related. Note that the Python clock() call, on Windows systems, is not using the system clock, but rather the finer resolution performance counters -- but the sleep() call is implied to be using the system clock [Python doesn't implement a sleep_until()]. >If you are saying the second, I think it is assumed >that the system time is an adequate measure of >physical (perfect) time. So the ideal time I describe >above is assumed to be what is outputted by now, and >that is assumed to be a adequately correct reading of >how much the delay (sleep_until) actually sleep, i.e. >its drift from the desired perfect periodicity. Let me try to put this into a more physical example... An old fashioned alarm clock... Set the alarm for, say, 6AM (this is the Delay_Until). Now, when the alarm goes off, you read the clock face to determine when it went off... The clock will show 6AM -- even if the clock is losing one minute per hour. After two days, the clock still shows the alarm going off at 6AM, but it is going off 48 minutes away from a standard clock. What your numbers are showing, to the best of my interpretation, is the equivalent of you going somewhere else in your house and waiting for the delay to expire (the alarm goes off), and then running through the house to get to the room with the clock and reading the face and using /that/ as the time it went off (6:02 if you had to navigate a few floors) ("that" is the latency from when the OS detected the delay expired and rescheduled the tast through to when the read operation captured the clock value). -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/