Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn ) Newsgroups: net.unix-wizards Subject: Re: question about unix & real time Message-ID: <5633@brl-tgr.ARPA> Date: Wed, 7-Nov-84 12:05:18 EST Article-I.D.: brl-tgr.5633 Posted: Wed Nov 7 12:05:18 1984 Date-Received: Sat, 10-Nov-84 04:03:48 EST References: <39@uwvax.UUCP> Distribution: net Organization: Ballistic Research Lab Lines: 36 > ... 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".