Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Timers Message-ID: Date: 7 Sep 90 04:27:56 GMT References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com> <11187@alice.UUCP> <1990Aug23.022416.14798@sco.COM> <26196@bellcore.bellcore.com> <10383@pt.cs.cmu.edu> <3760@osc.COM> <10403@pt.cs.cmu.edu> Sender: news@ux1.cso.uiuc.edu (News) Organization: Center for Reliable and High-Performance Computing University of Illinois at Urbana Champaign Lines: 58 In-Reply-To: lindsay@gandalf.cs.cmu.edu's message of 7 Sep 90 00:09:20 GMT Terminology: We want regularly scheduled events at times n*Tp Jitter errors give us events at times n*Tp+epsilon_n, where epsilon_n is some small random variable. Drift errors are of the form n*Tp + SUM for i from 1 to n of epsilon_i. Note that since epsilon_i may not have a symmetric distribution the errors may accumulate. Some of the previous posters have called drift errors creep errors. Let's not get too hung up on terminology. Some jitter is inherent in any timer event (except perhaps hardware signals caused by the timer) due to software indeterminacy, caches, bus traffic, etc. Drift, however, can be compensated for in most conventional timers. In a count-down timer, you can try to compensate for drift if the timer continues to count down. You read the count down timer, compare it to what it should have been, use it to adjust the next timer value you write. Essentially, this gives you twice the jitter, but you can adjust for drift long term. If you have a reload register, it can be set for regular periods of one cyclic process. But if you have two cyclic processes of incommensurate cycles, you have to reload the timer register anyway, which gives the same increased jitter problem. If you have an atomic exchange with timer operation, you can use this to adjust for drift - it's equivalent to reading the underflowing timer register, with reduced indeterminacy between the timer read and the timer load. Atomic add to timer can be used in much the same way. All of these let you compensate for this cycle's error on the next cycle, giving you essentially twice the jitter. As Donald Lindsey has written, an absolute timer with comparators can be used to eliminate drift. It also reduces jitter, in that you only have to worry about the indeterminacy of one timer interrupt. A more serious example of drift is between two separate time sources - like when your "microsecond" timer is not quite in agreement with the wall clock. Typically, then you have to use the same sort of time warping methodologies that the fellow from Wien was talking about. But then you have to worry about distinguishing between people who really want your best approximation of a rate (I want this done 1000 times a second for all of this satellite's pass-over) and those who want your best approximation of an exact time. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]