Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Timers
Message-ID: <10403@pt.cs.cmu.edu>
Date: 7 Sep 90 00:09:20 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>
Organization: Carnegie-Mellon University, CS/RI
Lines: 42

In article <3760@osc.COM> jgk@osc.UUCP (Joe Keane) writes:
>>	NextTime = ...the minimum of some set of times...;
>>	DownCountRegister = NextTime - TOE_Register;
>>
>>then we still get schedule creep.
>I don't follow you here.  Whether or not we get schedule creep
>depends only on how we compute NextTime, which is an absolute time
>value.

You are correct, I misspoke. This case gives jitter, not creep,
because the TOE upcounter is always there to refer to, and in
absolute units.  

(As someone else pointed out, higher level software is the correct
place to keep the mapping of absolute ticks to absolute real-world
time units.)

While I'm at it, I'll point out that the code above is pseudocode.
Those are 64-bit quantities, which one obtains and manipulates
piecemeal.  Also, there's usually some futzing with the control
registers of some faraway chip.  Hence, it's that much more of a pain
to come up with the fudge factors.  Plus, if the code is
interruptible, it's hard to nail down the average case and the upper
bound.  

I'm sure that someone out there is saying "So, lock out interrupts".
That's bad: one should never lock out interrupts, given a choice.
(It makes other handler's worst-cases worse.) (Nor is it good to
design something that _has_ to be the highest priority device.) The
beauty of the upcounter/comparator design, is that the handler
_doesn't_ get more complicated (or impossible) if it has to be
interruptable.  The pseudocode I gave will work regardless.

To be fair to the downcounter design, there are timer chips out there
with a halfway fix.  They have a reload register, and the downcounter
is atomically reloaded from it at the interrupt.  It has been pointed
out to me that this fix is quite good, if you can leave some single
value permanently in the reload register.  However, if the software
has to reload the reload register, then there's a race.

-- 
Don		D.C.Lindsay