question about unix & real time

[Geoff Kuenning]

In article <5633 at brl-tgr.ARPA> gwyn at brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
>> ...  I've heard that Unix is not a good operating system 
>> for real-time applications, but I have a couple of questions:
>> 
>> 	-Just what is it about Unix that makes it ill-suited for
>> 		real-time applications?
>
>This is an old myth based partly on fact.
>
	[ list of reasons:  no IPC, no lock-in-memory, high-overhead file
	  system I/O, system call overhead for device control, no strict
	  priorities ]

All of these reasons are correct and are (or were) serious deficiencies in
Unix.  However, there are other problems with Unix as a real-time operating
system.  Consider the following, from Barry Schein at Boston University:

>I concur. I built a real-time portable pulmonary testing lab
>running on an LSI-11/2 off of only RX02s (with swapping etc).
>One person would be filling in questionairres while another
>would be getting a lung test (A/D, ~20KHZ, 14bit.) It worked
>fine, an occasional hesitation for a few seconds (but with an
>RX02 as a swap device whoddyaexpect?

"An occasional hesitation every few seconds?"  That's not what I call
real-time.  My definition of "real-time" goes like this:

    A real-time system is one in which, if some a certain time constraint
    is not met by the software, catastrophic failure of the system will
    result.

If you can handle a hesitation every few seconds, whether it's an RX02 swap
time or an Eagle swap time, you don't have a very tight real-time constraint.
In that case, Unix will work fine.  Of couse, so will MS-DOS.

Even worse is trying to use Unix in a situation that requires fast
interrupt response time.  Check out a comparitive ad for a real-time OS
sometime (e.g., the VRTX ad).  Interrupt latency is a big issue with people
who have major real-time constraints to meet.  For example, I worked on a
system that had to update a display at 60 Hz.  That gives you 16
milliseconds to do that update.  Good old Unix, though, assumes that it is
perfectly okay to shut off interrupts and go run four or five wakeup() calls
(I am talking about clock.c here).  This costs many milliseconds, which is
an unfortunately large percentage of the 16 I had available.

>UNIX being 'bad for real time' is a myth perpetrated by vendors
>who sell O/S's that are bad for anything else.

"Unix being okay for real time" is a myth perpetrated by people who have
undemanding real-time applications and who have never encountered a
demanding one.  A high-performance real-time operating system is an
extremely difficult thing to design, and you cannot afford to add features
that make the OS a nice development system if they will cost performance.
If you have a low-performance data collection operation, by all means use
Unix.  In fact, there is an amazing amount of real-time control being done
in BASIC, enough that Intel has announced a version of the 8052 with BASIC
built into an 8K internal ROM.

But I would hesitate to use Unix for control of a robotic arm.  If
you are trying to maintain fine control at a high sampling rate, you had
better find out what a 4-millisecond perturbation in the sample stream does
to your control equations before you spend a lot of money on a computer.
And you should be prepared for a very low interprocess communication rate,
even if you use shared memory.  (A process switch under Unix is very
expensive, especially prior to System III/V).
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff