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