adamm@necis.UUCP (Adam Moskowitz) (06/22/88)
I'm sure this has been asked before, but here goes again anyway . . . A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like operating system". I told him that VenturCom "claims" to sell such a beast, but some discussion of their product ensued that led to the following question: Assuming that you are doing something like data acquisition or process control, what is required to make an O/S "real-time"? The answer he and I came up with was this: the ability to have absolute control over the scheduling of processes. Is there anything else we're missing? I don't think so. However, I'd love to hear what other people think. We're not saying that there aren't other features that wouldn't be nice to have, but the heart of "real-time"-hood comes down to scheduling. So, given that, who makes what he needs? We know that Charles River Data Systems has something called UNOS that supposedly does that. Does it? Does anyone else know of anything else that is available? Since this might be a popular topic, I'll be sure to summarize whatever email I get. Thanx in advance. -- Adam S. Moskowitz ...!(backbone)!{necntc,encore}!necis!adamm "Long long ago, in a galaxy far far away, God said, "Let there be lips!" And there were lips. And they were good!" -- RHPS
john@frog.UUCP (John Woods) (06/23/88)
In article <649@necis.UUCP>, adamm@necis.UUCP (Adam Moskowitz) writes: > I'm sure this has been asked before, but here goes again anyway . . . > A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like > operating system". I told him that VenturCom "claims" to sell such a beast, > but some discussion of their product ensued that led to the following > question: > Assuming that you are doing something like data acquisition or > process control, what is required to make an O/S "real-time"? > The answer he and I came up with was this: the ability to have absolute > control over the scheduling of processes. > Is there anything else we're missing? The real hard-core Real-Time people generally consider the answer to be "guaranteed response time". If an event happens, a real-time programmer needs to know the absolute maximum time that it will take for a response. If a system holds interrupts masked while it paints itself green, taking arbitrarily long, that's no good at all. A guarantee of "1 second from level 6 interrupt to response" is the right thing, just not very good. "10 ms from level 6 interrupt to response" is much nicer. However, some people do work that they consider real time, yet they don't require that kind of guarantee (as long as it isn't a case of sometimes losing the system for an hour or two until the paint dries :-); for these people, flexible scheduling is sufficient. >So, given that, who makes what he needs? We know that Charles River Data >Systems has something called UNOS that supposedly does that. Does it? Does >anyone else know of anything else that is available? > UNOS provides two things of interest to people doing real-time (or at least fast response time) work: (1) a flexible priority scheduler, which allows you to set your control process to high priority so that it is the first thing to run when your interesting event happens, and (2) the ability to install extra processors in the system, each of which can run a real Real-Time Executive, because UNOS itself isn't yet deterministic enough (and because, as a multi-user operating system, it has a lot of overhead that really time-sensitive applications don't want). We have a development package for our "Dedicated Auxilliary Processors" (what most people would call slave processors) which is oriented to (but not really dependant on) VRTX (Hunter and Ready's real-time executive). If you're interested in UNOS itself, our address is Charles River Data Systems, 983 Concord Avenue, Framingham MA 01701. Actually that is our address even if you aren't interested, too :-). -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Guns don't kill people; I kill people.
rogers@ofc.Columbia.NCR.COM (H. L. Rogers) (06/23/88)
In article <649@necis.UUCP> adamm@necis.UUCP (Adam Moskowitz) writes: >I'm sure this has been asked before, but here goes again anyway . . . > >A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like >operating system". I told him that VenturCom "claims" to sell such a beast, >but some discussion of their product ensued that led to the following >question: > > Assuming that you are doing something like data acquisition or > process control, what is required to make an O/S "real-time"? I suggest you call Bill Corwin at Intel. He is chairman of the IEEE 1003.4 committee on real-time for Un*x. That committee was spawned by /usr/group in 1984-or-so and is doing some very nice work in defining the attributes of a real-time system. You were right about scheduling; it is crucial to have control of process priorities to guaranteee deterministic performance. But that's not all you need. Things like user access to I/O space, fast IPC, process memory residency to completion, etc. will buy you larger chunks of performance and *predictability*. > >So, given that, who makes what he needs? We know that Charles River Data >Systems has something called UNOS that supposedly does that. Does it? Does >anyone else know of anything else that is available? HP, IBM (allegedly), Masscomp, NCR. There are probably others...just can't think of them. -- ------------ HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM)
kluft@hpcupt1.HP.COM (Ian Kluft) (06/25/88)
/ adamm@necis.UUCP (Adam Moskowitz) / writes: > A friend of mine has asked to help him locate a "real-time UN*X or UN*X-like > operating system". [ ... ] > Assuming that you are doing something like data acquisition or > process control, what is required to make an O/S "real-time"? > > The answer he and I came up with was this: the ability to have absolute > control over the scheduling of processes. Two issues to note when looking for a real-time OS are kernel pre-emption context switching time Kernel pre-emption is an important one to consider on Unix because most Unix systems do not allow system calls to be interrupted. Of course, context-switching time is somewhat obvious because it affects the time between arrival of an interrupt and (re)starting a user process to handle the event. That's really what it comes down to. If a guarantee can be made of the amount of time it takes between an event and entering the code to handle it, an OS is considered real-time. Of course, if that time is too long, it isn't worth mentioning. [End of unbiased material] While everyone was mentioning the real-time Unix's they knew of, I thought I'd mention the one I work with. Hewlett-Packard's HP-UX is a full System V with extentions for BSD 4.2 and real-time. While I don't have the exact numbers for measured real-time response, I remember that they are measured in milliseconds, as would be expected. ------------------------------------------------------------ Ian Kluft RAS Lab hplabs!hprasor!kluft HP Network Systems Group kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------