Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!kitty!larry
From: larry@kitty.UUCP (Larry Lippman)
Newsgroups: comp.unix.questions
Subject: Re: real-time Unix Systems
Message-ID: <1951@kitty.UUCP>
Date: Fri, 21-Aug-87 18:00:35 EDT
Article-I.D.: kitty.1951
Posted: Fri Aug 21 18:00:35 1987
Date-Received: Sun, 23-Aug-87 04:09:09 EDT
References: <2663@bobkat.UUCP> <3438@islenet.UUCP>
Distribution: na
Organization: Recognition Research Corp., Clarence, NY
Lines: 50
Summary: Obtaining "quasi" real-time performance under standard UNIX...

In article <3438@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes:
> > Does anybody out there know anything about what kind of real-time
> > Unix systems are available? (for things like automation, 
> > control, robotics, etc...).
> 
> Why bother with real-time unix?
> 
> Dedicate some smaller processors, to the heavily time-dependant
> stuff, and let the unix system oversee the operation.  No sense
> getting mixed up with some funny/special version of unix if you
> don't have to.  And if you connect things together in a reasonable
> way problems should be easier to diagnose, and you won't be
> tying yourself to one particular vendor.

	The above advice is _exactly_ some of what my organization does
to apply standard Sys V UNIX versions to real-time applications.
	For example, for the past 3 years we have used 3B2's for
scientific instruments and process control applications.  We use slave
processors - in many cases simple 8051-based devices - to acquire data,
"time-stamp" it, and perform control functions.  These slave processors
all connect via high-speed serial lines.
	On the Intel Multibus machines (286-based, Intel 310/311) that
we use we run standard Intel XENIX 3.4, and use slave processor boards
to handle our external data acquisition and control functions.  These
slave processor boards communicate via DMA and have appropriate XENIX
drivers. 
	Intelligent and sometimes clever use of available UNIX functions
can be used to achieve what I jokingly call "quasi" real-time performance.
For example, use of system calls like plock(2), nice(2), along with
appropriate use of ipc functions (semaphores and shared memory) can
vastly improve performance of routines which are time-critical.
	I have looked at various real-time UNIX versions, and I do not
care for them in OUR applications.  Why?  Because these real-time versions
lack certain system calls and do NOT support many standard UNIX utilities.
I feel that the usefulness of UNIX as a multi-user, multi-tasking system
is that any user should be able to run what they want.  This is simply
not true on any real-time UNIX system that I have seen.  For example,
the last that I knew, there were NO real-time UNIX systems which would
support `vi'.  How can you have UNIX without `vi'?  1/2 :-) 
	As a serious example, if I have a chemical process control system
that is collecting data in real time, I feel that an engineer should be
able to log into a terminal and run any spreadsheet or other program he
wants with that data (at a lower priority, of course).  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.

<>  Larry Lippman @ Recognition Research Corp., Clarence, New York
<>  UUCP:  {allegra|ames|boulder|decvax|rutgers|watmath}!sunybcs!kitty!larry
<>  VOICE: 716/688-1231       {hplabs|ihnp4|mtune|seismo|utzoo}!/
<>  FAX:   716/741-9635 {G1,G2,G3 modes}   "Have you hugged your cat today?"