Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.questions
Subject: Re: real-time Unix Systems
Message-ID: <6317@brl-smoke.ARPA>
Date: Sat, 22-Aug-87 02:13:25 EDT
Article-I.D.: brl-smok.6317
Posted: Sat Aug 22 02:13:25 1987
Date-Received: Sun, 23-Aug-87 11:06:06 EDT
References: <2663@bobkat.UUCP> <3438@islenet.UUCP> <1951@kitty.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 38

In article <1951@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes:
>But I don't know
>of any real-time UNIX that is not essentially bound to specifically
>compiled application programs, some language support, and a simple editor.

"Real-time" is a buzz word without a sufficiently precise meaning.
Many years ago, I made some relatively small changes to 6th Edition
UNIX to support memory-locked, preemptively-scheduled processes
without doing damage to the normal mode of system operation.
John Quarterman developed a high-throughput data acquisition scheme
using double-buffering in a user-mode process pair that took advantage
of the features I just mentioned, combined with an appropriate
device driver.  A small amount of hardware FIFO buffering on the
input channels really helped.  And of course, for highest throughput
we would write the data to raw disk.

I think our system qualified as "real-time", whatever that term
is supposed to mean.  Sure, we had to write some code, but no more
than we would have had to do for any operating system.  I've read
claims that UNIX is no good for "real-time" computing for many
years, and my impression is that that myth spread from the
collection of lies, half-truths, and misrepresentations that were
introduced in the ARPA VMS-vs-UNIX debate back when the standard
ARPAnet host was being changed from a DECsystem-20 to a VAX.
(There was one famous article in particular, but I forget the
author's name.  For a couple of years one kept encountering
obvious parroting of that article.)

Now it probably IS true that one would have to work harder to use
(for example) 4.3BSD as the basis of a real-time application like
the data acquistion one I described.  That's simply because the
system has gotten a lot more complex over the years (with
addition of virtual memory, network protocols, etc.), so ensuring
a suitable operating environment for real-time processes is
harder.  The main key to getting decent real-time performance out
of any UNIX variant (while not hurting its normal operation) is
to make sure its scheduler offers suitable support.  Most UNIX
schedulers I've encountered so far need work in that area (sorry, Ken).