From owner-freebsd-hackers Thu Sep 11 18:01:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA14449 for hackers-outgoing; Thu, 11 Sep 1997 18:01:41 -0700 (PDT) Received: from seagull.rtd.com (dgy@seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA14441 for ; Thu, 11 Sep 1997 18:01:38 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.8.5/8.8.5) id SAA16409; Thu, 11 Sep 1997 18:00:32 -0700 (MST) From: Don Yuniskis Message-Id: <199709120100.SAA16409@seagull.rtd.com> Subject: Re: Realtime Programming Under FreeBSD? In-Reply-To: <199709111717.KAA20383@usr07.primenet.com> from Terry Lambert at "Sep 11, 97 05:17:08 pm" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 11 Sep 1997 18:00:31 -0700 (MST) Cc: dufault@hda.com, leec@adam.adonai.net, luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In the words of the world-renowned author, Terry Lambert: > > There are many issues in > > the fbsd kernel - it isn't reentrant, it isn't interruptible, > > interrupts are turned off in places, etc. > > These speak more to QOS (Quality Of Service) than to implementability, > actually. The longest possible latency path to a required functional > deadline determines the response claims you can make for HRT, IMO, > and has little bearing on hardness beyond that. The real FreeBSD > problems are scheduling order, followed by priority inversion issues > arising from non-exclusive commision of resources, once the scheduler > issues are worked out. > > > The "easy" way to add demonstrably correct hard real time to unix > > is to time multiplex the CPU. Degrade the CPU by a duty cycle, > > and dedicate the part you've stolen to running something completely > > orthogonal to the unix kernel. You've created a second virtual > > CPU where you can do hard real time. > > This addresses, crudely, the scheduling issue, but leaves the inversion > issue outstanding. To truly do this the "easy" way requires commision > of all necessary resources: disk, controller DMA time, etc.. Not > a trivial task, needing as it does driver level modifications to > allow, for example, cancellation of all outstanding tagged commands > to service the RT needs exclusively. Unless you dedicate controller > resources to RT, as well. Then there's the bus resources... Perhaps I read more into Peter's comments than he intended *but* I was under the assumption that his (perhaps too subtle?) statement that "running something completely orthogonal to the kernel" was intended to imply that there was *no* resource sharing (hence magically waving aside the priority inversion issues :>)? If *not*, then I believe the "processor reserves" approach would need to be more integrated into the kernel to make those claims... > > Your interrupt latency suffers > > in the normal world. You preempt the kernel, so you have to worry > > about any hidden real time requirements (typically associated with > > devices) in the normal kernel. There are obvious problems when > > interrupts are turned off in the normal kernel, etc. It is doable. > > Oh oh, I hear Terry sneaking up on me... > > Two things would help immediately, without needing to go to this > extreme. I think the "easy" way described is actually harder in > some ways than it would need to be. > > If you had (1) kernel preemption, and (2) a reschedulable interval > based one-shot timer, you would have the basis of a hard timing > constraint for when you could begin some act. That leaves issues I think the one-shot can be worked around (assuming the system tick is at a frequency "high enough for the timeliness constraints of the application") since you could just ensure the events are scheduled prior to the tick *before* the deadline, etc. (i.e. err on the earlier side) > of priority inversion of shared resources, but that handleable > through (a) lending, and (b) resource preeemption. The other Yikes, Terry... you make it sound like it's *trivial*!! :> ("I'll expect those changes on my desk before 5PM...") > issues are merely "hardness guarantee issues"... ie:, they indicate > how tight a deadline the sysem can conform to, not whether or not > the system can conform to any hard deadline at all. Note that > even if you are significantly over the quantum in start scheduling > leeway, the current system is incapable of guaranteeing to meet a > deadline. > > Anyway, this type of discussion is why there's a FreeBSD RealTime > list. Maintained by Peter, of course. 8-). Agreed. --don