Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff From: geoff@desint.UUCP (Geoff Kuenning) Newsgroups: net.unix-wizards Subject: Re: question about unix & real time Message-ID: <211@desint.UUCP> Date: Tue, 13-Nov-84 02:05:21 EST Article-I.D.: desint.211 Posted: Tue Nov 13 02:05:21 1984 Date-Received: Thu, 15-Nov-84 03:52:55 EST References: <39@uwvax.UUCP> <5633@brl-tgr.ARPA> Organization: his home computer, Thousand Oaks, CA Lines: 70 In article <5633@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug 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