Xref: utzoo comp.unix.xenix:2271 comp.unix.microport:646 comp.periphs:952
Path: utzoo!attcan!uunet!husc6!mailrus!ames!lll-tis!oodis01!uplherc!sp7040!obie!wes
From: wes@obie.UUCP (Barnacle Wes)
Newsgroups: comp.unix.xenix,comp.unix.microport,comp.periphs
Subject: Re: Thoughts needed
Summary: Exactly...
Keywords: Compaq xenix microport multi-user multiport
Message-ID: <230@obie.UUCP>
Date: 13 May 88 23:57:57 GMT
References: <4144@orstcs.CS.ORST.EDU> <224@obie.UUCP>, <1988May10.181259.1971@utzoo.uucp>
Organization: Great Salt Lake Yacht Club, north branch
Lines: 25

In some article, I embarass myself by saying:
> ...  A Unix (or unix-like)
> system is probably not your best bet for doing data acquisition on.
> Unix was designed from the beginning to be a time-share system, not a
> real-time system.

In article <1988May10.181259.1971@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) replied:
| There is nothing about Unix that makes it inherently unsuited to be a
| real-time system.  Real-time variants of it exist, and many labs have done
| quite extensive real-time work under it.  All that having been said, Unix
| as it usually comes out of the box isn't well adapted to real-time work.
| Unless you have a version that has been adapted, or are capable of doing
| it yourself, you're probably better off with a program loader (e.g. MSDOS)
| that gives your program absolute control of the hardware, rather than a
| real operating system (e.g. Unix) that may insist on playing some part
| in things at inopportune times.

Exactly, and well put.  Most "real-time" systems have some way of
specifying a minimum repsonse time expected to any event you are
waiting on.  On vanilla Unix, the best you can do is crank the
priority for the daq process way up.  MS-DOS allows you to load your
program and write files on the disk in a fairly reasonable manner, and
won't get in the way of your response time (hopefully).  Coming up
with a task scheduler in such a situation, however, is your own
problem.  Good Luck.  :-)