fish@aati.UUCP (William G. Fish) (01/10/88)
Why is "plain vanilla" UNIX considered inferior for realtime applications
and what can be done to improve its realtime capabilities? I've seen
sync system calls cause a UCSF RTP (Real Time Process system call)
process to miss deadlines. Must a realtime process kill /etc/update?
Bill Fish Analysis & Technology
321 River Road 153 Williams Street
Mystic, CT 06355 New London, CT 06320
(203) 536-3301 (evenings) (203) 444-7722 (days)
(203) 536-0137 (2nd line) ihnp4!{hsi,rayssd}!aati!fishgwyn@brl-smoke.UUCP (01/12/88)
In article <449@aati.UUCP> fish@aati.UUCP (William G. Fish) writes: >Must a realtime process kill /etc/update? That's what I used to do. The sync() system call initiates a lot of high-priority kernel work, which is hazardous to the performance of a real-time application.
mlight@hpiacla.HP.COM (Mike Light ) (01/14/88)
> Why is "plain vanilla" UNIX considered inferior for realtime applications > and what can be done to improve its realtime capabilities? The heart of the issue is quick servicing of interrupts and transference of control to a process monitoring a device (let's call it a "Control Rod" for example). There are Windows of Time where an O/S's tables or state information would appear "inconsistent" should a process be allowed to execute right then. Thus, to guarantee rapid notification and processing of a Control Rod interrupt, any O/S Inconsistency Windows need to be of very short duration. In instrumenting a vanilla 4.2 BSD kernel, for example, there were windows of up to 4 milliseconds (14,000 instructions on the particular machine) where the O/S could not allow a process to execute. Even one-half millisecond is too long for many device-control processes. Through some judicious reworking of algorithms in the 4.2 kernel, the average Inconsistency Window was reduced to something like 300 instructions, which met the 100 microsecond goal. We call it "HP-UX/RT", Playing at an HP Sales Office near You! -- Mike Light.
davel@hpcupt1.HP.COM (Dave Lennert) (01/15/88)
> In instrumenting a vanilla 4.2 BSD kernel, for example, there were > windows of up to 4 milliseconds (14,000 instructions on the particular > machine) where the O/S could not allow a process to execute. The window I measured was more than 1 SECOND. These measurements and the HP-UX kernel mods to fix them are discussed in: "Decreasing Realtime Process Dispatch Latency through Kernel Preemption", USENIX Conference Proceedings, Summer 1986, pp. 405-413. For a discussion on the other needed real time facilities that are provided in HP-UX see: "UNIX for Real Time", UniForum Conference Proceedings, January, 1987, pp. 219-230. -Dave Lennert HP ihnp4!hplabs!hpda!davel uunet!hpda!davel