Date: Thu, 11 Sep 1997 18:00:31 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: tlambert@primenet.com (Terry Lambert) Cc: dufault@hda.com, leec@adam.adonai.net, luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <199709120100.SAA16409@seagull.rtd.com> In-Reply-To: <199709111717.KAA20383@usr07.primenet.com> from Terry Lambert at "Sep 11, 97 05:17:08 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120100.SAA16409>