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>