From owner-freebsd-current Thu Jul 8 11:24:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8D6D914F1E; Thu, 8 Jul 1999 11:24:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA70100; Thu, 8 Jul 1999 11:23:43 -0700 (PDT) Date: Thu, 8 Jul 1999 11:23:42 -0700 (PDT) From: Julian Elischer To: Doug Rabson Cc: Seigo Tanimura , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this is problematic. you cannot add a new element before the pending firing because you can't tell how far into the present trigger you are. On Thu, 8 Jul 1999, Doug Rabson wrote: > On Thu, 8 Jul 1999, Seigo Tanimura wrote: > > > On Wed, 7 Jul 1999 19:46:38 -0700 (PDT), > > Julian Elischer said: > > > > julian> With your scheme the clock needs to be always running at elevated speed. > > julian> Possibly you might have a startup routine that turns on the elevated > > julian> frequency, (basically does an 'aquire_timer0()' ) I would say that you > > julian> would have more success in implementing your finetimer() by using > > julian> "aquiretimer0" than the other way around. > > > > I agree that acquire_timer0() would give more freedom to the ticks > > to callout. Then I tried figuring out how to manage multiple > > callouts using acquire_timer0(), which is something like below. > > > > > > Let C the callout queue, and c_i a callout. (0 <= i < I) Next define f(c_i) as > > the callout function of c_i, and dt_rem(c_i) the time span between c_(i-1) and > > c_i. (dt_rem(c_-1) is defined as zero) We use the time span to avoid traversing > > though the queue to update the time tags on the callouts. > > > > (footnote: I'd better write in TeX :-<) > > > > Queueing a new callout c' to be made in t' involves a problem to find the > > maximum j (which is an integer, j >= 0) satisfying a constraint > > > > t' > \sum_(k=0)^(j) dt_rem(c_k) > > > > where the right hand side of the inequality is the time span after which > > the callout c_k is made. Then c' is inserted after c_j and new dt_rem(c_(j+1)) > > and dt_rem(c_(j+2)) are determined. Now we can acquire_timer0() with dt_rem(c_0). > > > > In clkintr(), we dequeue c_0 from C, and make a callout to f(c_0). Then > > acquire_timer0() is called once more with the new dt_rem(c_0). dt_rem(c_i) is > > the difference of callout times, so they need not be updated on every clkintr(). > > > > > > Although the computational cost in clkintr() is generaly O(1), the queueing cost > > is O(I). Not sure whether we can reduce it or not (will it really make a trouble?) > > > > > > How does it sound? > > If I understand this correctly, you are suggesting that we program timer0 > so that we only take interrupts when a finetimer is due to fire? If so, > then it sounds very good. The idea of taking 6000+ interrupts/sec made me > uneasy, even though most would return without doing any work. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message