Thoughts needed

Barnacle Wes wes at obie.UUCP
Sat May 14 09:57:57 AEST 1988


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 at utzoo.uucp>, henry at 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.  :-)



More information about the Comp.unix.microport mailing list