planting@uwvax.UUCP (W. Harry Plantinga) (11/06/84)
I am interested in using a smallish computer, like a Sun workstation
or a micro Vax, for a real-time application (controlling a robot arm
with sensors). 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?
-Does anyone know of a "real-time" system on the order of
a Sun, preferably running Unix? Preferably with
good graphics?
-Harry Plantinga
arpa: planting@wisc-rsch.arpa
use: {inhp4, seismo}!uwvax!plantinggwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/07/84)
> ... 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. - Except under UNIX System V, there is no good support for real-time IPC (if the task needs it; not all do). Signals and pipes are inadequate. - Older UNIXes had no way to keep a process from being swapped out, so there could be a significant delay in responding to real-time events. - The file system (block I/O) involves a fair amount of overhead. This can be avoided by use of "raw disk". - Except under 7th Edition UNIX, device control involves system call overhead. This can be avoided if your device-control module is implemented as a kernel process (e.g., a "smart" device driver). - The UNIX scheduler does not support the concept of strict priorities, so a high-priority process may not be able to gain exclusive use of system resources when it needs them. All these drawbacks can be overcome by a competent UNIX system programmer. At my previous employer, we successfully implemented a system based on 6th Edition UNIX on an LSI-23 that acquired large amounts of data onto a Winchester disk at around 100KHz, with a very small amount of hardware buffering. At slightly slower rates, concurrent multi-process background number-crunching and interactive graphic display was supported. As I said, "a myth".
geoff@desint.UUCP (Geoff Kuenning) (11/13/84)
In article <5633@brl-tgr.ARPA> gwyn@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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/16/84)
> 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. Geoff made some good points about using UNIX for real-time applications. My definition of "real-time" would be similar to his, and my claim is that UNIX can be adapted to real-time use in this sense with a modest amount of work; indeed, as I pointed out, we did so. However, such an application requires careful consideration and design, and control over the suite of processes that may be running (e.g., "sync" is outlawed). I would agree that UNIX in its present form does not support a wide range of different real-time applications, nor would a simple small set of changes support such a range. Interrupt latency can be improved dramatically by putting UNIX's critical regions under semaphore control rather than the simplistic interrupt lock-out that is currently used. This is not a small change but people have done it for certain versions of UNIX. I would like to see this in the "standard" version of UNIX also.
boyle@ANL-MCS.ARPA (11/16/84)
In regard to: >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. I may be naive, but I assumed when Barry Schein at Boston University said that there was an occasional hesitation, he meant in the (non-realtime) filling-out-the-questionnaire part of the application rathern than in the real-time lung-test-data-gathering part.
ado@elsie.UUCP (Arthur David Olson) (11/17/84)
brl-tgr!gwyn-- > Interrupt latency can be improved dramatically by putting UNIX's critical > regions under semaphore control rather than the simplistic interrupt > lock-out that is currently used. The interrupt lock-out used by UNIX is simple rather than "simplistic." -- UNIX is an AT&T Bell Laboratories trademark. -- ..decvax!seismo!elsie!ado (301) 496-5688 DEC, VAX and Elsie are Digital Equipment and Borden trademarks
bsa@ncoast.UUCP (Brandon Allbery) (11/21/84)
The original reply (whatever *that* means :-) quoted the original message as
saying "a hesitation every few seconds", where it really said "an occasional
hesitation for a few seconds". there's a big difference; is 'occasional'
something like 5 times a day?
--bsa
--
Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp!
6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa
(216) 524-1416 \ 44131 | E1439@CSUOHIO.BITNET (friend's acct.)
---------------------------------------+---------------------------------------
Forgive; we just had a system crash & lost a month's worth of work and patches.God <root%bostonu.csnet@csnet-relay.arpa> (11/25/84)
> The original reply (whatever *that* means :-) quoted the original > message as saying "a hesitation every few seconds", where it really said > "an occasional hesitation for a few seconds". there's a big difference; > is 'occasional' something like 5 times a day? > > --bsa Oh for the love of ...: The first prototype (built by Emil Millet, circa 1976) ran on an LSI11/2 with 4KW memory running his own O/S and a one line LED tty and a tape cassette. It was portable and went out into the field to factories gathering pulmonary function tests from thousands of Meat Wrappers and B.F. Goodrich rubber workers and many other studies. The later one I built was based on V6 UNIX (circa 1978) running on 32KW and a two drive double density floppy. It had a DRV11-J and a real/time board/clock from ADAC. It swapped to the floppies! it was portable! it was before the Apple and its ilk and it was more sophisticated in that at least it could do enough time sharing to allow questionnaire data to be collected while real-time was happening. Now you sound like the world was plastered with microvaxes and 68000s and within that critical context you ask your questions...SUCH THINGS DID NOT EXIST THEN...MOST PEOPLE WHERE I WORKED AT HARVARD WERE STILL USING 80 COL CARDS ON BATCH. (were you around then?) [Thanks, I feel better now.] -Barry Shein