Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!kent From: kent@swrinde.nde.swri.edu (Kent D. Polk) Newsgroups: comp.realtime Subject: Re: AmigaDOS as realtime system? Message-ID: <1698@swrinde.nde.swri.edu> Date: 4 Mar 91 18:21:32 GMT References: <1991Feb27.090231.5412@newcastle.ac.uk> <1991Feb28.194655.1294@eecs.wsu.edu> <91061.164211KKEYTE@ESOC.BITNET> Sender: news@swrinde.nde.swri.edu Organization: Southwest Research Institute, San Antonio, Texas Lines: 88 In article <91061.164211KKEYTE@ESOC.BITNET> KKEYTE@ESOC.BITNET (Karl Keyte) writes: >Since you all seem to have worked on Nuclear reactor controllers, space >shuttles, Space stations, etc., you clearly know lots about real-time >systems. No space shuttles or Space stations :^) Just things like movable reactor core flux mapping systems, RC pump monitoring systems, reactor startup monitoring systems and 'loose parts' monitors. Most of these systems used fairly basic RT capabilities. The exceptions are my last flux mapper and some of the stuff I've done on the Amiga, as the Amiga provides more RT features than all of my other RT boxes did except HP-UX's boxes. (They were much easier to implement on the Amiga also :^) >The conversations, however, about Amiga's suitability for real-time >applications seem to be more directed towards it's ability to act as >a rapid process controller. The theoretical (& we'll start getting >very pedantic if we take it much further) definition of "real-time" >addresses issues such as process scheduling (assuming of course that >whatever system is being used is capable of handling more than one >concurrent process), interrupt priorities, system service reentrancy, >context switch time, preemptive scheduling, and much more. > >There aren't many "real-time" Operating Systems around that stand up >to the definition. Since the Amiga argument is starting to test the >definitions, I think we should close that one. Someone did point out >that there is a difference between very fast and real-time, and it's >certainly true. Let's just say that the Amiga is very fast (for some >things), and can control some external devices at an acceptable level >of service. > I fear I am about to exhaust the patience of net readers, so I will try to wrap this thing up & will no longer respond to postings as a result. I will gladly discuss via email if you want to pursue this thread further. The Amiga has much more than just the ability to "control some external devices at an acceptable level of service." I have done that with MSDOS boxes, yet I don't consider MSDOS boxes to be realtime systems as I had to throw out all MSDOS features & use it only to start things up. Also, 12 MHz AT throughput under load was more than 3 orders of magnitude slower than that obtained with a 14 MHz '020 Amiga. That is why I posted the information about my system. The only thing in question regards the inability of the O.S. to guarantee response times. Everything else needed by a RT system is there, and implemented fairly nicely. The whole O.S. appears to be written with the goal of achieving realtime video processing on the base 68000 Amigas. It does this very nicely. Many O.S. functions have been highly optimised to provide this RT environment. Messages are essentially signals with a message structure attached. This results in the highly efficient messaging system which appears to be an order of magnitude faster than similarly-powered boxes. Software interrupts get a hardware assist which results in another order of magnitude increase in response times. Shared interrupts are pre-processed even before they get passed to the 68xxx cpu. Microhertz resolution hardware timers provided allow very accurate response times. Semaphores are unique (as far as I know) in that they can be implemented directly in the structure of the resource that they are arbitrating. These semaphores can be either signal or message-based - again with the message-based ones incurring only the extra overhead of reading the message structure and replying to the message. Many more RT services are also provided. I.e. the Amiga has many O.S. and hardware provided RT functions which I wish were implemented on my other RT systems. As a result I will state that the Amiga provides all necessary RT services except guaranteed response times and provides them with typical response times which are at least an order of magnitude faster than similar-powered boxes. Also that while the system doesn't guarantee response times, other facilities provided can be used programattically to provide guaranteed response times under many conditions. It can do this without requiring external front-end processors which even many of my guaranteed response time boxes had to have to achieve the needed RT response times. Also the Amiga is an incredibly fun box to program on, as very little effort is required to get enormous returns. I didn't want to start anything here. Just wanted to provide the UseNet community with information which might be very useful in context. Please take it at face value. Thanks, Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent (Disclaimer - the nuke systems mentioned occured before my employment at SwRI)