From owner-freebsd-hackers Thu Sep 11 12:16:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA11209 for hackers-outgoing; Thu, 11 Sep 1997 12:16:24 -0700 (PDT) Received: from seagull.rtd.com (dgy@seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA11196 for ; Thu, 11 Sep 1997 12:16:19 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.8.5/8.8.5) id MAA21425; Thu, 11 Sep 1997 12:14:42 -0700 (MST) From: Don Yuniskis Message-Id: <199709111914.MAA21425@seagull.rtd.com> Subject: Re: Realtime Programming Under FreeBSD? In-Reply-To: <199709110933.FAA23225@hda.hda.com> from Peter Dufault at "Sep 11, 97 05:33:38 am" To: dufault@hda.com (Peter Dufault) Date: Thu, 11 Sep 1997 12:14:42 -0700 (MST) Cc: leec@adam.adonai.net, luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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