DMS%MIT-OZ@MIT-MC.ARPA (04/24/84)
From: David Siegel <DMS%MIT-OZ@MIT-MC.ARPA> Hi, We are planning to use a Vax 11/750 in a real time control application. Rumor has it that Unix is not very good for real time control. This leads to two questions: 1) Is the rumor true, and if so what are the problems? 2) Are there any verions of Unix floating around that are especially designed for real time applications. Note: We are using the vax to servo actuators for a robot at rates that vary from 40 to 300 cycles per second. We will be needing interrupt response from the vax, although it is not clear how fast a response rate we need. Should we stick with VMS, or will some Unix handle our needs adequately? Thanks for any help you can give. -Dave & Sundar
gwyn@Brl-Vld.ARPA (04/25/84)
From: Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> With suitable mods to the scheduler, plus plock(2), it is quite possible to use UNIX for real-time control. Last place I worked we had an 11/23 UNIX acquiring data at rates up to several KHz.
rpw3@fortune.UUCP (04/30/84)
#R:sri-arpa:-13200:fortune:26900054:000:2036
fortune!rpw3 Apr 29 19:38:00 1984
UNIX does not provide the real-time features you are probably
used to in DEC operating systems, but if your requirements
are not too complex, there are two "tricks" (often used in
network implementations), one of which may work for you.
Both require that you have kernel (at least driver) sources
and a kernel guru "on-call".
1. You will need a special device driver for your funny hardware
anyway, right? Simply provide a "ioctl" which waits for the
next "interesting" event from the interrupt level and returns
some kind of data about what the event was, etc. If the driver
"sleeps" at "positive" priority (x >= PZERO), the process will
be able to swap out while sleeping, and conversely. Swapping
lessens contention for memory, but gives poorer response.
This version assumes all of the computation runs in user space,
and the driver just handles the interrupt data capture.
2. If you can't even stand the time it takes a memory-resident
UNIX process to "return" from an ioctl, put the ENTIRE real-time
task in the driver. At system boot time (or whenever), a tiny
user program opens /dev/realtime (your driver). The driver never
returns from the open, but runs as a user process in kernel
mode, sleeping when appropriate. Since it has a "user process",
it can do disk I/O and other things "user processes" can do.
The overall point is that UNIX has all kinds of "real-time" features
in the kernel (sleep/wakeup and "timeout" [scheduled events]) for
managing the concurrency of its I/O system -- they're just not
(readily) available to user processes. Therefore, the time-critical
portions of your task must run as kernel code. The simplest way to do
this is to bury it in the device driver you use to talk to your hardware.
As I said above, several implementations of network software have taken
this approach.
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065