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: Fri, 21 Nov 2014 22:06:03 +0100 Organization: Aioe.org NNTP Server Message-ID: <87k32oi7r8.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> <87d28h1cj9.fsf@debian.uxu> <3apu6ap126abi6oalch9vpre20hjij2uon@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:O7t6cYdh2TmKFqsCDCaCQOQ3RAw= Mail-Copies-To: never Xref: news.eternal-september.org comp.lang.ada:23615 Date: 2014-11-21T22:06:03+01:00 List-Id: Dennis Lee Bieber writes: >> 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. OK. I'll CC this to my teacher (including the full quotes of your message) and see what he says. Intuitively, I think it is clear: time is perfect but the clock isn't, it is a close but never perfect estimate of time, and if there is a drift away (which of course it'll always be, otherwise you could just reset the clock if it was "correctly" off by some constant margin), i.e., with a drift, with time, the clock will be even worse (i.e., further away from time). >> "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. 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? 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. (Again, I'm CC-ing this to my teacher, hopefully he'll mail me and I'll get back on this, anyway this is how I always assumed the situation so this discussion is really great if it helps to remove a misunderstanding.) > 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. Yes, now I understand what you mean. I think it is agreed that time is good enough for the purposes of this project. This isn't about examining the lack of quality of the stuff in general, it is about specifically logging the "over-delay" of sleep_until which now() is deemed capable of. > 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. """ -- underground experts united