Date: Thu, 11 Sep 1997 17:17:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dufault@hda.com (Peter Dufault) Cc: 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: <199709111717.KAA20383@usr07.primenet.com> In-Reply-To: <199709110933.FAA23225@hda.hda.com> from "Peter Dufault" at Sep 11, 97 05:33:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > According to Stevens (et al), hard real-time programming (which > > is what 1ms timing is) is not reliably possible on un*x... Don Yuniskis covered this in great, gory, and (IMO) accurate detail, so I won't comment on the original post directly. But Peter is right, I am sneaking up. > 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... > 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 of priority inversion of shared resources, but that handleable through (a) lending, and (b) resource preeemption. The other 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-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111717.KAA20383>