tims@infidel.lanl.gov (Tim Sullivan) (02/19/91)
I just saw a posting in which AmigaDOS was described as a realtime multitasking operating system. Can anyone shed light on its realtime abilities? Tim Sullivan (tims@infidel.lanl.gov)
shields@yunexus.YorkU.CA (Paul Shields) (02/19/91)
tims@infidel.lanl.gov (Tim Sullivan) writes: >I just saw a posting in which AmigaDOS was described as a realtime >multitasking operating system. Can anyone shed light on its realtime >abilities? Well, the exec is a real-time kernel called Intuition, with prioritized interrupt response and task scheduling, message passing & semaphores, asynchronous i/o, shared memory, and lots of hooks into dynamic exec data structures. Well-documented system calls make extensions such as a new device driver easy to install and use in a running system. I've been developing audio software on Amiga for the last 4 months, and have familiarized myself with certain of these features. It is straightforward, for example, using standard calls to the "audio.device" driver, to write a 4-channel sound player utilizing Amiga's DMA system and built-in 8-bit D/A converters to get smooth, continuous sound in stereo. ... Paul Shields disclaimer: I have no connection with Commodore's marketing department. The company I work for is a registered developer.
epa@phobos.cis.ksu.edu (Eric P. Armstrong) (02/22/91)
shields@yunexus.YorkU.CA (Paul Shields) writes: >tims@infidel.lanl.gov (Tim Sullivan) writes: >>I just saw a posting in which AmigaDOS was described as a realtime >>multitasking operating system. Can anyone shed light on its realtime >>abilities? >Well, the exec is a real-time kernel called Intuition, with Actually there are three parts to the Amiga operating system. There is the executive kernel that does what is described below. The second part is AmigaDOS which handles the file system. And then there is Intuition, which is the windowing manager. If you wish you can toss out any or all of the 3 parts, although this reduces some of the features of the system. But on a dedicated system this may be desireable. >prioritized interrupt response and task scheduling, message passing & >semaphores, asynchronous i/o, shared memory, and lots of hooks into >dynamic exec data structures. Well-documented system calls make >extensions such as a new device driver easy to install and use in >a running system. ---- Eric Paul Armstrong Kansas State University Bitnet: ericpaul@ksuvm.bitnet Internet: epa@phobos.cis.ksu.edu
peter@taronga.hackercorp.com (Peter da Silva) (02/23/91)
In article <21695@yunexus.YorkU.CA>, shields@yunexus.YorkU.CA (Paul Shields) writes: > Well, the exec is a real-time kernel called Intuition, No, the kernel is called "Exec". Intuition is the window system. -- (peter@taronga.uucp.ferranti.com) `-_-' 'U`
kent@swrinde.nde.swri.edu (Kent D. Polk) (02/23/91)
In article <TIMS.91Feb18122523@infidel.infidel.lanl.gov> tims@infidel.lanl.gov (Tim Sullivan) writes: >I just saw a posting in which AmigaDOS was described as a realtime >multitasking operating system. Can anyone shed light on its realtime >abilities? > >Tim Sullivan (tims@infidel.lanl.gov) There have been two other postings which mention features of the Amiga operating system which qualify it as 'real time'. There is only one point which would call this classification into question, and it is that there are no guaranteed response times, and in fact, one process can easily take over the complete system. I believe this to be a very minor point, as in actual use, an Amiga attains typical response times which are easily an order of magnitude quicker that many other realtime OS's using the same processor platform. This is in a loaded configuration. For example, I use Amiga's for research-oriented real-time data acquisition and manipulation in a scheme which you probably have seen before - that of a 'conveyor belt' with typically one 'sampler' process which gathers data (in my case groups of waveforms and other info associated with an 'event') and places it in a shared mem buffer which is of variable size, according to how many 'events' I wish to buffer. A message is popped off of a message stack & associated with that event just placed in the buffer and sent to a message address obtained from a semaphore- controlled, doubly linked list of 'belt' processes. After the process at that message address is finished with the event, it passes the message along to the next in the list, until things get back to the sampler. Each message structure contains several items, including generic commands and intermediate results that are passed from one filter to another. Intermediate results are passed in the message structure to keep the data 'pure' for any filters which may want to take a snapshot of the data or tee off to other process paths. This semaphore-controlled list allows me to insert or delete 'filter' processes to operate on the data in any order at any time. Especially when data is moving through the belt. Individual filters can be controlled using the window/gadget environment extremely easily as I use a generic template which has to be filled out and linked with the main filter program which handles all of the 'belt' system overhead. I use the gadget-oriented approach to controlling my filters, as the very nice programming environment on the Amiga makes gadgets easier to program than any other method. Better get back to the subject. Anyway, some of my samplers pull data from multiple sources as the result of an event generated by an external interrupt. On a 25MHz equipped 68030 Amiga with 8 processes active on the belt and about 65 total tasks running on the system, response times for events with a 7 msec duty cycle as measured with a logic analyser were typically within 25 microseconds. The isr was written in 'C'. Since the external interrupts on the Amiga are shared, the isr first polled the hardware to determine if it generated the interrupt, read the system clock, two environment variables, 10 channels of waveform information, did some housekeeping and sent either 1 or 2 signals off to other processes to inform them of particulars that it found. This executed within 90 microseconds. So far I haven't seen the need to even optimise the C, much less do the isr in assembler. BTW, software interrupts even get a hardware assist, so they operate about an order of mag. faster too. The Amiga is so quick, responsive and easy to program compared to any other real-time system that I have used that I have been adopting it for for use in other low-end data-acq. research projects. It has turned into a very nice real-time lab front-end for our Sun network because of this and it's ease in blending in with the network in general. One thing I would also like to point out is that this system uses OS calls and resources entirely. No assembler is needed and the OS abounds with extremely useful functions such as the system linked-list manager which I use to handle all my lists. This box is easier to program than a unix box since it does use simpler mechanisms for IPC, but it's all there, and lots more fun to program on :^) Even after reading this simple example, wouldn't you agree that Amigas qualify as having a real-time OS? Thumbs up! Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
A.Waterworth@newcastle.ac.uk (A Waterworth) (02/27/91)
kent@swrinde.nde.swri.edu (Kent D. Polk) writes: >In article <TIMS.91Feb18122523@infidel.infidel.lanl.gov> tims@infidel.lanl.gov (Tim Sullivan) writes: >>I just saw a posting in which AmigaDOS was described as a realtime >>multitasking operating system. Can anyone shed light on its realtime >>abilities? >> >>Tim Sullivan (tims@infidel.lanl.gov) > . > . >The Amiga is so quick, responsive and easy to program compared to any >other real-time system... > . > . >Even after reading this simple example, wouldn't you agree that Amigas >qualify as having a real-time OS? I probably won't be the only one to mention this, but here goes anyway... Being quick, responsive, etc. is not necessarily being real-time. The important characteristic of a real-time computer system is that it must be _predictable_. That is to say, it must be able to offer guarantees of a specified level of service provision under specified timing constraints. Simply being fast or responsive isn't enough, although such features often make the job of meeting those 'specified timing constraints' so much easier. For example, supposing that you have a process control task which absolutely must be performed within 750ms. Can the Amiga OS _guarantee_ that that task will never (in the absence of faults or failures) miss its deadline? If it cannot make such a guarantee, then it isn't a real-time OS - although it might act as a decent starting point from which to develop one. Profound apologies to all of those people out there who are sick of listening to the constant "What is/isn't real-time?" bickering which seems to be affecting the field at the moment, but I honestly think that the common misconceptions about real-time being the same thing as blindingly fast should be cleared up. Adrian. P.S. If the last paragraph sounds a bit pompous, I'm sorry - no offence was intended to anyone. (So we'll all forget about any little flame wars before they even start. Won't we?) ______________________________________________________________________________ FROM : Adrian Waterworth. JANET : A.Waterworth@uk.ac.newcastle ARPA : A.Waterworth@newcastle.ac.uk PHONE : +44 91 222 6000 UUCP : ...!ukc!newcastle.ac.uk!A.Waterworth POST : Computing Lab. University of Newcastle upon Tyne, UK. NE1 7RU.
pcooper@eecs.wsu.edu (Phil Cooper - CS495) (03/01/91)
In article <1991Feb27.090231.5412@newcastle.ac.uk> A.Waterworth@newcastle.ac.uk (A Waterworth) writes: >kent@swrinde.nde.swri.edu (Kent D. Polk) writes: > >>In article <TIMS.91Feb18122523@infidel.infidel.lanl.gov> tims@infidel.lanl.gov (Tim Sullivan) writes: >>>I just saw a posting in which AmigaDOS was described as a realtime >>>multitasking operating system. Can anyone shed light on its realtime >>>abilities? >>> >>>Tim Sullivan (tims@infidel.lanl.gov) >> . >> . >>The Amiga is so quick, responsive and easy to program compared to any >>other real-time system... >> . >> . >>Even after reading this simple example, wouldn't you agree that Amigas >>qualify as having a real-time OS? > >I probably won't be the only one to mention this, but here goes anyway... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well, you are the first one so far... > > For example, supposing that you have a process control task which >absolutely must be performed within 750ms. Can the Amiga OS _guarantee_ that >that task will never (in the absence of faults or failures) miss its deadline? >If it cannot make such a guarantee, then it isn't a real-time OS - although it >might act as a decent starting point from which to develop one. > > Adrian. > Adrian, it should be obvious to you that any OS which operates in an interrupt-driven environment (not to mention multitasking), would fail the requirements you have set forth for a real-time OS. If you are collecting data and monitoring events from several different sources, some with higher priority than others, an unfortunate sequence of interrupts could prevent lower level requests from being processed. In reality, this would be a rare (if not unheard of) event, but still plausible. To meet your requirements you would need a single-tasking, polled I/O system with a seperate micro- processor dedicated to each data collection (I/O) port. And then, you would need to ensure that your processing code would complete its work before the next event arrived (every time). Or, you could buffer the events to be processed, but what if the buffer fills? Also, if you are going to take someone to task about a posting, please do not edit it so much that it is barely recognizable. Kent Polk's posting was very informative, and provided an excellent example of how Amigas are used to do real-time processing. It may not meet your definition, but then, I don't know of any OS in existence that does. Are you an expert in the internals of the AmigaOS? Have you ever used an Amiga for real-time processing? Have you ever even SEEN an Amiga? I thought not. -Phil- P.S. Please insert :-)'s where appropriate :-) -- /********************************************************************\ * Real Life: Phillip R. Cooper * * Email: pcooper@yoda.eecs.wsu.edu * * Disclaimer: Disclaimer?? I don't need no stinkin' disclaimer!!! *
A.Waterworth@newcastle.ac.uk (A Waterworth) (03/01/91)
pcooper@eecs.wsu.edu (Phil Cooper - CS495) writes: >In article <1991Feb27.090231.5412@newcastle.ac.uk> A.Waterworth@newcastle.ac.uk (A Waterworth) writes: >> >>I probably won't be the only one to mention this, but here goes anyway... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [ My stuff about predictability in real-time operating systems etc.] > > Well, you are the first one so far... Well, it comes as a surprise to me that I am 'the first one so far' - maybe most of the people I know who are working on real-time hardware and software don't read this group? > Adrian, it should be obvious to you that any OS which operates in an >interrupt-driven environment (not to mention multitasking), would fail the >requirements you have set forth for a real-time OS. Not necessarily - a decent real-time OS should be sufficiently predictable in it's own behaviour and flexible in the services which it provides that it will allow an application programmer to write software in such a way that guarantees of timeliness _can_ be made for some critical subset of real-time tasks (possibly all of them). That should be true even in an interrupt-driven, multi-tasking environment. (Any specification of a real-time system should include information about the frequency and relative importance of asynchronous events such as interrupts, as well as information about which tasks need to be run and under what conditions. Given such data, interrupt handling and multi-tasking can then be handled in a predictable fashion - although you may find that the available hardware is not powerful enough and you've got to fork out more cash!) > If you are collecting >data and monitoring events from several different sources, some with higher >priority than others, an unfortunate sequence of interrupts could prevent >lower level requests from being processed. In reality, this would be a rare >(if not unheard of) event, but still plausible. To meet your requirements >you would need a single-tasking, polled I/O system with a seperate micro- >processor dedicated to each data collection (I/O) port. And then, you >would need to ensure that your processing code would complete its work >before the next event arrived (every time). Or, you could buffer the events >to be processed, but what if the buffer fills? Of course, this raises the old issue of soft and hard real-time tasks. If you are performing some kind of data-logging or data acquisition and you occasionally miss deadlines, then it doesn't really matter - you can probably afford to miss the occasional sample (unless you're working on something extremely strange). However, the types of real-time task which I have had to consider over the past few years are much more unpleasant - they're the kind of task where missing deadlines can, at best, cost you $$$$$ and, at worst, get people killed. Under such conditions, you just do not want to be falling outside your timing constraints - period! When data acquisition is required as part of some task set in such a system, then it must be performed in such a way that it cannot lead to a catastrophic failure (so it either has to be pre-empted when more important things happen or you have to be sure that it's going to work right every time). > Also, if you are going to take someone to task about a posting, please >do not edit it so much that it is barely recognizable. Kent Polk's posting >was very informative, and provided an excellent example of how Amigas are >used to do real-time processing. Now just a minute pal - you're starting to get on my wick here. 1. I was not taking Kent Polk to task about his posting. It _was_ informative and did provide an excellent example of how Amigas are used to do "real-time" processing. Except that the original question was whether AmigaOS is a real-time operating system and I was simply pointing out that it may offer a good starting point from which to develop one, but it is lacking in certain features which would make it suitable for general, or more particularly hard, real-time use. 2. I edited so much of the original posting out because I didn't want to go burning up bandwidth. I reckon anyone who was interested in this topic in the first place would have read the original article anyway, don't you? >It may not meet your definition, but then, I don't know of >any OS in existence that does. It's not just my definition - it's also the definition of a number of research groups and projects across the world. I'm not going to name drop because I don't need to - just check out any decent University library for recent (and even not so recent) papers. Oh, and you're right - at the moment there isn't any OS in existence that does meet the definition, although there are some that are starting to come close. Why do you think that there are large amounts of money being spent in the US, Europe and elsewhere to support leading-edge academic and industrial research into real-time systems? It certainly ain't being spent for the fun of it. >Are you an expert in the internals of the >AmigaOS? Have you ever used an Amiga for real-time processing? Have you >ever even SEEN an Amiga? I thought not. Of course I've seen an Amiga (silly boy!) OK, I will grant that I am no expert in the 'internals of AmigaOS' and that I have never used one for real-time processing. The latter is largely because it simply couldn't _do_ the kinds of real-time processing which I am considering (see above). However, having said that, does spending the last three years of your life working with research projects in real-time and safety-critical systems count for anything? I think that it probably should...?? Adrian. P.S. I'm still not 'taking anyone to task', so would people please refrain from ranting before they start. If I ever do have a real go at somebody's posting, believe me, you'll know about it. ______________________________________________________________________________ FROM : Adrian Waterworth. JANET : A.Waterworth@uk.ac.newcastle ARPA : A.Waterworth@newcastle.ac.uk PHONE : +44 91 222 6000 UUCP : ...!ukc!newcastle.ac.uk!A.Waterworth POST : Computing Lab. University of Newcastle upon Tyne, UK. NE1 7RU.
kent@swrinde.nde.swri.edu (Kent D. Polk) (03/02/91)
In article <1991Mar1.100809.27673@newcastle.ac.uk> A.Waterworth@newcastle.ac.uk (A Waterworth) writes: >pcooper@eecs.wsu.edu (Phil Cooper - CS495) writes: > >>In article <1991Feb27.090231.5412@newcastle.ac.uk> A.Waterworth@newcastle.ac.uk (A Waterworth) writes: >>> >> Adrian, it should be obvious to you that any OS which operates in an >>interrupt-driven environment (not to mention multitasking), would fail the >>requirements you have set forth for a real-time OS. > > Not necessarily - a decent real-time OS should be sufficiently >predictable in it's own behaviour and flexible in the services which it >provides that it will allow an application programmer to write software >is not powerful enough and you've got to fork out more cash!) Oh my. What did I start here :^) I guess I should respond, no? I agree with both of you, depending on what the job is. I also think both sets of answers were very good. I start: Deadlines: The Amiga O.S. does not guarantee response times. I used to hesitate in calling the Amiga O.S. a realtime system until I studied the situation a bit more, after which I believe it is. One way to get around deadline problems on the Amiga is to use one of the very functional async timers. In this case a failure to respond would trigger a signal upon which you can take action to 'correct' the failure of a deadline from being met. This obviously has some drqwbacks but it is there. Now this requires a bit more programming, and I wouldn't want to do this for very many tasks, but the nice part about the Amiga is that 'tasks' can be broken up so easily, without loosing much in the 'process'. Sure, this requires a bit more design effort, but can really result in very nice, well-behaved systems. >occasionally miss deadlines, then it doesn't really matter - you can probably >afford to miss the occasional sample (unless you're working on something >extremely strange). However, the types of real-time task which I have had >to consider over the past few years are much more unpleasant - they're the >kind of task where missing deadlines can, at best, cost you $$$$$ and, at >worst, get people killed. Under such conditions, you just do not want to >be falling outside your timing constraints - period! When data acquisition >is required as part of some task set in such a system, then it must be >performed in such a way that it cannot lead to a catastrophic failure >(so it either has to be pre-empted when more important things happen or >you have to be sure that it's going to work right every time). Good choice. I would not be using an Amiga in life-critical situations either. But again, I don't think that eliminates it from the list of real-time computers, It just means that it would be a poor choice in this instance. I have also developed real-time systems that were in very critical enviroments - such as reactor cores. Not only did they have to be real-time, but my software had to take into account EVERY conceivable problem that could be defined to possibly occur. Very long list. Some of the conditions were simply to stop the system, issue a priority warning to the operator & expect him to decide what to do. Others included fairly intricate algorithms for determining what happened and what to do about it. (Pre-cognitive AI? :^) I used Intel RMX on earlier projects and then moved to HP RT boxes with custom front-ends after finally coming to the conclusion that Intel didn't know how to correctly build anything but microcontrollers. >> Also, if you are going to take someone to task about a posting, please >>do not edit it so much that it is barely recognizable. Kent Polk's posting >>was very informative, and provided an excellent example of how Amigas are >>used to do real-time processing. Blush :^) It's ok, I pretty much agree with his comments in the context he provided. I posted the message to let other realise that a low-cost alternative to what are usually very expensive RT boxes is available - for what I consider the 'lab' environment. Note that just like other personal computers, the Amiga is not ruggedized and is not appropriate for many RT tasks for that reason also. In closing, I again believe it is fairly easy to create a nice real-time system using an Amiga, and have it be typically much more responsive than most other RT systems based on some other similar powered box. I also noted that I was using them for RT lab data- acquisition. I think Amigas are an excellent choice for this type of application - where nobody gets hurt if it misses a couple of events here and there - as long as it knows about them. They also offer a very nice environment for massaging the data after the test & producing professional reports - all in one box. Very handy. Lastly, I believe I can always use the standard response - "get a faster cpu" :^) Thanks for your responses. Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
KKEYTE@ESOC.BITNET (Karl Keyte) (03/03/91)
Since you all seem to have worked on Nuclear reactor controllers, space shuttles, Space stations, etc., you clearly know lots about real-time systems. 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. ======================================================================== Karl Keyte Phone: +(49) 6151 902041 European Space Operations Centre Fax: +(49) 6151 90495 Robert-Bosch Strasse 5, D-6100 Darmstadt, Germany ========================================================================
kent@swrinde.nde.swri.edu (Kent D. Polk) (03/05/91)
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)