From owner-freebsd-questions Fri Feb 6 08:52:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10719 for questions-outgoing; Fri, 6 Feb 1998 08:52:00 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from cerberus.partsnow.com (gatekeeper.partsnow.com [207.155.26.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10685 for ; Fri, 6 Feb 1998 08:51:53 -0800 (PST) (envelope-from don@PartsNow.com) Received: (from bin@localhost) by cerberus.partsnow.com (8.8.5/8.6.9) id IAA00575; Fri, 6 Feb 1998 08:46:50 -0800 (PST) X-Authentication-Warning: cerberus.partsnow.com: bin set sender to using -f Received: from nouvelle(192.168.100.9) by cerberus.partsnow.com via smap (V2.0) id xma000564; Fri, 6 Feb 98 08:46:27 -0800 Message-ID: <34D9ED0B.78DC@PartsNow.com> Date: Thu, 05 Feb 1998 08:47:07 -0800 From: Don Wilde Reply-To: don@PartsNow.com Organization: Soligen, Incorporated X-Mailer: Mozilla 3.0C-E-KIT (Win16; I) MIME-Version: 1.0 To: "Lee Crites (AEI)" CC: Jean-Marc Henriette , freebsd-questions@FreeBSD.ORG Subject: Re: Real time capability and FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe questions" > =>Real Time capability to FreeBSD, or should I not even bother? I know that > =>Linux has a RT version of their stuff, but I don't want to have to learn > =>how to manage a linux box when FreeBSD makes it so much easier.. > > My first question is what do you mean by "real time" capability? > Here are some possible options: > > 1) you want data which is manipulated by one user to be seen > right away by another user; > > 2) you want things happening now, as opposed to at some time in > the future; > > 3) your processes depend upon data arriving in a deterministic > way every time. > > The first two options are what some people call "soft" real-time. > I've been able to manipulate/contort many versions of un*x, > including FreeBSD into handling soft-real-time quite easily. > > Number three is where some of the purists will probably part ways > with me. I can accept a hard-real-time definition which takes > time constraints into consideration. The pure definition has > nothing to do with time, only the arrival of data happening in a > deterministic fashion -- and, of course, on time. > > I focus more on the "on-time" aspect. I figure if there is a, > say, +/- 30% variance from the average, and I can handle the data > arriving at 130% of the average, then I'm a happy guy. The fact > that the system isn't exactly deterministic in nature, coupled > with what many of the purists would call a totally unacceptable > variance, don't cause me any grief. > > So (and this is why I have gone to the trouble of explaining the > above), *I* find FreeBSD capable of handling my hard-real-time > application as well. FreeBSD has the capability of manipulating > the priority of a process so it can hog as much of the system as > it needs, which is what I exploit. Your mileage will vary. > > This brings me to the second question: what is it you want to > do? Or, put another way, what are your real needs? > > Armed with that tidbit of data, I might be able to help more. Lee has summarized well. I have spent years dealing with hard real-time applications in microcontroller assembly language, so I have a bit of experience here. His explanation of the different definitions in common use for 'real time' is something it is well worth your time to reflect on. There are very few applications in the real world where true hard-real-time guaranteed maximum latency is needed, and almost always these are best handled by a little slave processor with a good interrupt controller on it. A human's perception of 'real time' usually can handle a latency of multiple milliseconds, which to any computer is an eon. Several years ago, I was one of the primary programmers for the Javelin security system line. Its base operating system was DOS, and it was designed to control a camera matrix of up to 1000 cameras and 1000 monitors and 1000 alarm points, all monitored through a daisy-chained SERIAL PORT @ 9600 baud. Needless to say, each 4-byte query took 4 milliseconds, and polling the entire alarm array took multiple seconds, even with local microcontrollers that would respond with an alert for each bank of alarm points. Despite this already-very-obsolete technology, the Javelin system was installed at both the Pentagon and the White House, as well as numerous airports and large hotel complexes. Obviously, with DOS, one has total control of latency, since there are no other programs competing for attention. But then, you never had any intention of running real-time programs on the same machine as a public news server, right? -- oooOOO O O O o * * * * * * o ___ _________ _________ ________ _________ _________ ___==_ V_=_=_DW ===--- Don Wilde [don@PartsNow.com] [http://www.PartsNow.com ] /oo0000oo-oo--oo-ooo---ooo-ooo---ooo-ooo--ooo-ooo---ooo-ooo---ooo-oo--oo