Date: Thu, 11 Sep 1997 12:14:42 -0700 (MST) From: Don Yuniskis <dgy@rtd.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: <199709111914.MAA21425@seagull.rtd.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
In the words of the world-renowned author, Peter Dufault: > > According to Stevens (et al), hard real-time programming (which > > is what 1ms timing is) is not reliably possible on un*x... [here lies the infamous "1mS" reference -- Sorry, Joerg, but I like the S capitalized! :>] > Hard real-time programming is independent of time base and is > usually defined by being deadline driven, e.g., the glass bottle Exactly! > picker upper snatching bottles off the conveyer belt. When you Ah, I'll have to remember that example... > are late you smash the bottle. There is no time base you can > identify as being "hard real time". There are many issues in > the fbsd kernel - it isn't reentrant, it isn't interruptible, > interrupts are turned off in places, etc. Right. There are no "guarantees" that the kernel can make regarding the timeliness of it's services (oh, I suppose you *could* argue that they are all in the interval (0, 3days] :> but that's kinda silly! :>). So, unless you can completely avoid *all* services aupplied by the kernel (inclucing scheduling! :-/), you can't realistically address RT issues. > 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 Yes. Unfortunately, this is nontrivial as you *really* need to ensure this orthogonality -- *nothing* can be in contention! A sort of brute force "processor reserves" implementation... > CPU where you can do hard real time. 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... That's all right... just hand him your wallet and any jewelry you happen to have... --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709111914.MAA21425>