From owner-freebsd-hackers Thu Sep 11 03:24:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA12328 for hackers-outgoing; Thu, 11 Sep 1997 03:24:09 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA12323 for ; Thu, 11 Sep 1997 03:24:05 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA23225; Thu, 11 Sep 1997 05:33:39 -0400 (EDT) From: Peter Dufault Message-Id: <199709110933.FAA23225@hda.hda.com> Subject: Re: Realtime Programming Under FreeBSD? In-Reply-To: from Lee Crites at "Sep 10, 97 03:17:02 pm" To: leec@adam.adonai.net (Lee Crites) Date: Thu, 11 Sep 1997 05:33:38 -0400 (EDT) Cc: luigi@labinfo.iet.unipi.it, jamil@counterintelligence.ml.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (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 > 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