Date: Thu, 11 Sep 1997 05:33:38 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: leec@adam.adonai.net (Lee Crites) Cc: luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <199709110933.FAA23225@hda.hda.com> In-Reply-To: <Pine.BSF.3.95.970910145537.9159A-100000@adam.adonai.net> from Lee Crites at "Sep 10, 97 03:17:02 pm"
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... Hard real-time programming is independent of time base and is usually defined by being deadline driven, e.g., the glass bottle picker upper snatching bottles off the conveyer belt. When you 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. 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. 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... Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709110933.FAA23225>