Richard Neitzel (06/28/88)
Here at NCAR we are (or at least will be) using several realtime operating systems and kernals. However, in so far I as I know, there is no net group that has this special interest at heart. Therefore I am asking two questions: 1> Is there a mailing list for realtime OS's in general or any particular flavor in isolation? 2> Is there any interest in a realtime news group? Thanks, Richard Neitzel Computer Scientist National Center for Atmospheric Research
jca@homxc.UUCP (J.ANTROSIGLIO) (06/28/88)
In article <10450@udenva.cair.du.edu>, Richard Neitzel writes: > 2> Is there any interest in a realtime news group? I vote yes! -- John C. Antrosiglio AT&T Bell Laboratories Crawford Corner Road Holmdel, New Jersey 07733 ihnp4!{homxc|hotlf|hotld}!jca
young@pur-ee.UUCP (Mike Young) (06/28/88)
Richard, (1) I, for one, know of no existing forum for realtime OS discussions; and, (2) I'd like to see one started! Anyone else? Mike Young Purdue University EE Dept young@eg.ecn.purdue.edu
linimon@killer.UUCP (Mark Linimon) (06/29/88)
In article <10450@udenva.cair.du.edu>, Richard Neitzel writes: > 1> Is there a mailing list for realtime OS's in general or any > particular flavor in isolation? > > 2> Is there any interest in a realtime news group? > > Richard Neitzel This answer may be a little bit more than wanted, because for me realtime OS's tend to be bound to particular implementations. I discuss what I know discussions on the net about both, below. The closest thing is the newsgroup comp.periphs, where bus-based systems tend to be discussed, including VMEbus, which tends to include system discussions of things like VxWorks occasionally, or other kernels. VxWorks came up as a discussion point in comp.protocols.tcpip as well. There is a "VMEbus" mailing list, heavy quotes here, it only applies to the AT&T processor board which has about .01% of the market. Typical AT&T marketing. Not much discussion of the software. There are at least 4 VMEbus companies on the net, in general I think they just tend to read and not contribute, like Mizar has. There is a comp.os.os9 (I think that's the name) group for the OS/9 operating system. Microware (the authors) are in on it but the group is fairly quiet. Comp.os.misc picks up on real-time but only rarely. As for me, I would be interested in either mailing lists or newsgroups on the following: 1. Real-time systems, such as VxWorks, VRTX, pSOS, etc. (disclaimer: Mizar uses first two out of those three). 2. Bus-based products, such as VME, Multibus I/II, STD, Nubus, Futurebus, etc. Possibly the charter of comp.periphs could be expanded to include the latter, since it does by default anyway, possibly also the former if people feel it is worthwhile. I'm willing to accumulate emailed replies in terms of interest, and/or ^^^^^^^ to serve as a reference point, moderator, or whatever would help. Mark Linimon Mizar Digital Systems uucp: sun!convex!mizarvme!linimon killer!linimon ;guest account snail: 1419 Dunn Drive Carrollton, TX 75006 (214)446-2664 x8044
ward@cfa.harvard.EDU (Steve Ward) (06/29/88)
In article <4631@killer.UUCP>, linimon@killer.UUCP (Mark Linimon) writes: > In article <10450@udenva.cair.du.edu>, Richard Neitzel writes: > > 1> Is there a mailing list for realtime OS's in general or any > > particular flavor in isolation? > > > > 2> Is there any interest in a realtime news group? > > > > Richard Neitzel I would like to see a realtime OPERATING SYSTEM discussion group, so make my vote "yes." >
eugene@pioneer.arpa (Eugene N. Miya) (06/30/88)
I'm somewhat interested in real time OS (for spacecraft control), but
I don't think many manufacturers of machines are interested because
most do surpisingly poor time keep on systems (this is an artifact, and
outcome, not a requirement). They view the market
place as small. This is too bad. SO what are the topics?
A good notation (please Ada(tm) isn't the end all 8-)
scoping (time, syntactic, semantic) rules
Tasking control (interface)
Exception handling (exception scope)
I/O
Realtime in a uniprocessor environment versus a multiprocessor
environment
Types of hardware support (or lack of)
Obviously many others
The event model of real time is kind of a shitty model. So start
discussing and justify the need for a RTOS group.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."jerry@wrs.UUCP (Jerry Fiddler) (06/30/88)
In article <10450@udenva.cair.du.edu> Richard Neitzel writes: >Here at NCAR we are (or at least will be) using several realtime operating >systems and kernals. However, in so far I as I know, there is no net group >that has this special interest at heart. Therefore I am asking two questions: > > 1> Is there a mailing list for realtime OS's in general or any >particular flavor in isolation? Not that I know of, although we have toyed with the idea of setting one up for VxWorks specifically. > 2> Is there any interest in a realtime news group? Definitely! I put out the same inquiry over a year ago and got some interest, but I never followed up through all the right channels. Let me know if I can be of any help. -- Jerry Fiddler Wind River Systems {sun,rtech}!wrs!jerry
lee@turing.unm.edu (Lee Ward) (06/30/88)
Why not start the discussion in this group and if traffic warrants create another? os.misc doesn't have a lot of traffic so it shouldn't be too much trouble should it? --Lee (Ward)
yuval@taux01.UUCP (Gideon Yuval) (07/02/88)
I think a comp.os.realtime newsgroup would be a good idea.
--
Gideon Yuval, yuval@taux01.nsc.com, +972-2-690992 (home) ,-52-522255(work)
Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel
(alternative E-mail address: decwrl!nsc!taux01!yuval@uunet.uu.net)ken@cs.rochester.edu (Ken Yap) (07/03/88)
Well look, the traffic in this newsgroup is so underwhelming so why not post the realtime OS stuff here? I would read it. If there is enough traffic you can justify another newsgroup. This "we need a newsgroup before we can have a discussion" is a stale argument. Look what happened to comp.std.internat and comp.fonts. Ken
webber@aramis.rutgers.edu (Bob Webber) (07/04/88)
In article <11053@sol.ARPA>, ken@cs.rochester.edu (Ken Yap) writes: > Well look, the traffic in this newsgroup is so underwhelming so why not > post the realtime OS stuff here? I guess the first question is: why are realtime OS's rare. Is it really so difficult to modify schedulers to give a certain process a guarenteed slice of cpu, guarenteed memory residence, and perhaps even priority on disk fetches? Of course, my own interests are in being able to do on a Sun the kind of graphics you can do on an IBM PC. This basically means being able to guarentee that certain things will get done in a given 60th of a second time slice. Is this the same neighborhood the ``real'' realtime people are interested in, or do they want finer grain control? --- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber) p.s., > I would read it. If there is enough > traffic you can justify another newsgroup. This "we need a newsgroup > before we can have a discussion" is a stale argument. Look what > happened to comp.std.internat and comp.fonts. comp.fonts is a perfectly fine comp.* group. comp.std.internat is as good as any comp.std.* group (definitely a weak branch in the tree).
braun@drivax.UUCP (Kral) (07/05/88)
In article <Jul.4.06.44.39.1988.24362@aramis.rutgers.edu> webber@aramis.rutgers.edu (Bob Webber) writes: >I guess the first question is: why are realtime OS's rare. Is it really >so difficult to modify schedulers to give a certain process a guarenteed >slice of cpu, guarenteed memory residence, and perhaps even priority on >disk fetches? In my opinion the difficulty in Real Time OSs is *not* in the scheduler algorithm, but in guaranteeing a low maximum interrupt latency, and still providing useful services for the applications people to use. You have to be able to guarantee that any interrupt, or at least any interrupt of a set of classes of interrupt, be able to get service in a minimum amount of time. Furthermore, you have to be able to transfer control to high priority applications logic within a guaranteed amount of time. There is a trade off between offering a good set of services for the appications people (while still guaranteeing response time) - and thus giving them quick development time - and letting them have control over everthing, which means they have to do most of the work themselves (the OS just provides a kernel). -- kral 408/647-6112 ...{ism780|amdahl}!drivax!braun "I'll let you be in my dream If I can be in yours" DISCLAIMER: If DRI knew I was saying this stuff, they would shut me d~-~oxx
eugene@pioneer.arc.nasa.gov.arpa (Eugene N. Miya) (07/05/88)
Real-time OS are rare for several reasons. Don't "real-men" program
these? [I'm a wimp myself.] Seriously, consider the consequences of
many of these OSes: x-ray machines, radar systems, cars, weapons
systems, robots, assembly lines. Why, you can kill people with some of
these (as James Burke would say). I know one CS prof who believes a
RTOS is no different from any other OS, but I know others who put them
into completely different categories. Until this riff is resolved,
you will have RTOSes.
More students need to be shaken up and they have to work with these.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."linimon@killer.UUCP (Mark Linimon) (07/06/88)
In article <Jul.4.06.44.39.1988.24362@aramis.rutgers.edu>, webber@aramis.rutgers.edu (Bob Webber) writes: > Of course, my own interests are in... > being able to guarentee that certain things will get done in a given > 60th of a second time slice. Is this the same neighborhood the ``real'' > realtime people are interested in, or do they want finer grain control? > > --- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber) > To some extent, the phrase "real-time" has become marketingspeak. Several classes of applications exist. Heavy image processing applications may require response down in the 1 to 10 microsecond range. (Obviously beyond a certain point you have to build dedicated hardware, sometimes in conjunction with a slower microprocessor. This is fairly common). Machine control applications oftentimes are satisfied by response times in the low milliseconds. Most anything moving a stepper motor or engaging a solenoid will be in this category. As far as I can tell the common denominator that various people use the "real" in "real-time" to mean, is that the response is *guaranteed* to happen within this time. In this sense an (untweaked) Unix kernel is not real-time, due to its statistical behavior. (Several manufacturers have done such tweaking, by the way). I am currently trying to gather together my notes and lists of various real-time products on the market. Further input solicited by email, I will try to summarize to this newsgroup within two weeks, maybe by the end of this week. Mark Linimon Mizar Digital Systems sun!convex!mizarvme!linimon
ron@topaz.rutgers.edu (Ron Natalie) (07/06/88)
Real time OS's aren't much harder than anything else. Most computer manufactueres offer their own real-time operating systems, the problem is that there is no real portable, nice OS like UNIX to do real time. Mostly because the demand just isn't there. We live in a time share world. Many of us who have worked in research labs have hacked real time support into UNIX of one sort or another. As is usually the case in RealTime support in a timesharing operating system, you essentially give tyrannical powers to certain user mode processes. Hence, real time really works best on standalone systems. _Ron
daveb@geac.UUCP (David Collier-Brown) (07/06/88)
In article <3574@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >In article <Jul.4.06.44.39.1988.24362@aramis.rutgers.edu> webber@aramis.rutgers.edu (Bob Webber) writes: >>I guess the first question is: why are realtime OS's rare. Is it really >>so difficult to modify schedulers to give a certain process a guaranteed >>slice of cpu, guaranteed memory residence, and perhaps even priority on >>disk fetches? In article <3574@drivax.UUCP> braun@drivax.UUCP (Kral) writes: >In my opinion the difficulty in Real Time OSs is *not* in the scheduler >algorithm, but in guaranteeing a low maximum interrupt latency, and still >providing useful services for the applications people to use. > >You have to be able to guarantee that any interrupt, or at least any interrupt >of a set of classes of interrupt, be able to get service in a minimum amount >of time. Furthermore, you have to be able to transfer control to high priority >applications logic within a guaranteed amount of time. > >There is a trade off between offering a good set of services for the >applications people (while still guaranteeing response time) - and thus giving >them quick development time - and letting them have control over everything, >which means they have to do most of the work themselves (the OS just provides a >kernel). Well, you can simplify the problem of providing response substantially by considering different scheduling **strategies**. By "strategy", however, I mean something much different from giving some process a guaranteed slice of cpu (guaranteed memory residence, priority on I/O, etc). David Cheriton proposed scheduling processes at system load time, based on knowledge of the time require to complete a given time-critical task and its frequency. This allows one to put a bound on what processes will be allowed to be run in "real time" on a given processor with known interrupt latency and known process-switch times. The result is that you don't really have priorities at all, you have requirements and resources to satisfy them. It is surprising how much easier this can make the "guarantee performance" problem (:-)). It is, of course, not sufficient. You still need fast interrupts and process switches for faster and faster real-time requirements. It merely takes the risk and kludgery out of the configuring and makes it easier to satisfy some real-time tasks on a machine with a rich (Unix-like) suite of software development capabilities. See Cheriton on "The V System" (sorry, I've lost the correct reference) and the rumor mill re the new Japanese real-time kernel... --dave (I remember Thoth) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers Ltd., | "His Majesty made you a major 350 Steelcase Road, | because he believed you would Markham, Ontario. | know when not to obey his orders"
baker@necbsd.NEC.COM (L. BAKER) (07/06/88)
From article <3574@drivax.UUCP>, by braun@drivax.UUCP (Kral): > In my opinion the difficulty in Real Time OSs is *not* in the scheduler > algorithm, but in guaranteeing a low maximum interrupt latency, and still > providing useful services for the applications people to use. > > You have to be able to guarantee that any interrupt, or at least any interrupt > of a set of classes of interrupt, be able to get service in a minimum amount > of time. ...you have to be able to transfer control to high priority > applications logic within a guaranteed amount of time. > > There is a trade off between offering a good set of services for the > appications people (while still guaranteeing response time) - and thus giving > them quick development time - and letting them have control over everthing, > which means they ... do most of the work themselves (the OS just provides a > kernel). I do real-time programming for a living, and I have a few comments. I don't claim to be a wizard or even merely knowledgable about generic real-time operating systems, but I have learned a few things over the last year that apply. First, it's not the interrupt itself that requires a minimum response time, it's the event that that interrupt represents. Consider, for example, a thing that acts as a `timer' - causing a prescheduled `time-out' event to occur at a specific moment. This may not work well with a hardware clock, since only a finite number of time-out interrupts can be set. To handle a large number of prescheduled events, or events that are scheduled beyond the immediate resolution of the clock, a `clock handler' has to exist that repeatedly resets the clock and checks to see what's being activated at this particurlar interrupt. The time-out `event' that the clock interrupt would represent, and the task/process/code that will have to be started to handle it are what require the fixed minimum latency. The actual hardware clock handler is itself really an interrupt handler. Anything it activates is an event handler. With this model of real-time computation the events, as initiated by the hardware interrupt-handlers, are the fundamental schedulable entities. It may be more important, for example, to handle something that requires 0.001 sec. resolution than something that requires 1.0 sec resolution. Rather than treat the individual event handlers as time-share entities with priority levels, the higher-priority item is handled first, because of the priority level of the event that activated it, then the lower priority one. This gaurentees that the events requiring the lowest latency times receive the fastest response. So to me the difference between a generic real-time system and a generic something else kind of system *is* the scheduler. The scheduler is no longer scheduling processes per se, but scheduling events. Any additional scheduling that is required in the traditional sense, e.g. spreading around unused CPU to other processes that can use it, becomes a `background' consideration. Also, If you accept this distinction then there really isn't an application layer; the event driven nature of the system turns the entire application into one huge state-machine model of the computation being performed. Thus the `applications' are really the event handlers and the subsystems they control. In a sense, the `events' are themselves software interrupts. But since they are software entities, similar to messages in a message passing operating system, they can be traced, controlled and simulated. This makes software development and testing for these systems far more manageable since the scenaios being tested are much easier to simulate and reproduce. Larry Baker, NEC America Switching Systems Division, Dallas TX Uucp: { harvard | husc6 | ames }!ut-sally!necssd!baker Internet: baker%necssd.uucp@cs.utexas.edu
stan@shell.com (Stan Hanks) (07/12/88)
Just a quick question, while we're talking about realtime OS:
what is the nominal interrupt dispatch time for Unix (time from the
the hardware interrupt line being yanked until your interrupt handler
is executing)?
If you post some info on this, please include
* the type of hardware you are using
* the which version of Unix you are using
* how you determined the time involved
Thanks. If you mail direct to me, I'll summarize to comp.os.misc.
Please post follow-ups to comp.os.misc.
Stan Hanks
Research Computer Scientist, (and Postmaster!)
Shell Development Company, Bellaire Research Center (713) 663-2385
...!{sun,psuvax,soma,rice,decwrl,cs.texas.edu,ihnp4}!shell!stan stan@rice.edu
Stan Hanks
Research Computer Scientist, (and Postmaster!)
Shell Development Company, Bellaire Research Center (713) 663-2385
..!{sun,psuvax,soma,rice,decwrl,ut-sally,ihnp4}!shell!stan stan@rice.edujerry@wrs.UUCP (Jerry Fiddler) (07/13/88)
I think Larry has put his finger very well on one aspect of a real-time system;
that of being event-driven. Just for discussion's sake, here's a list of
some of the other requirements that I usually think of as differentiating a
real-time from a non-real-time environment.
- Event-Driven
This is an essential difference from something like a Unix system. A
real-time system's primary function is usually to to respond to real-world
events and act upon them in a timely and predictable fashion.
- Pre-emptive, multi-tasking scheduler
The scheduler must be absolutely pre-emptive; e.g. the highest priority
task that is ready to run at any given time must be running. When a high
priority task becomes ready (presumably because of a real-world event,
I/O completion, or timeout) it must pre-empt any lower priority task
that might currently be running.
An corrolary of this idea is that is critical to minimize the times that
the OS itself does not allow task pre-emption. For instance,
when a low priority task is in the OS itself, can it be
pre-empted? This is a serious architectural consideration.
- Easy Connection To And Prompt Response To Interrupts
Because most real-world events announce themselves to the computer
as interrupts, it is important for an application to connect and
respond to interrupts easily and effectively.
- Effective Communications Between Tasks, and Between Task and Interrupt Level
Most real-time problems seem to require multiple tasks working on
the same problem. This is essentially different than, for
instance, a typical timeshare system where there is minimal
(hopefully) interaction between, say, two different editors run by
two people. Therefore, there is often considerable communications
between the tasks. Also, since most processing should be done at
task level (for prioritization and queueing purposes) it is
important to be able to easily communicate from interrupt to task
level. For these reasons, the communications models are usually
different for real-time systems.
- Closeness to Hardware
In Unix-like systems, the application is kept as isolated as
possible from the underlying hardware. In a real-time system,
where the application needs to interact with the real-world,
this is not desirable.
- Ability to Run with Available Resources
Diskless? ROM-based? Minimal RAM? This, of course, is
application-dependent.
- Ability to keep things locked in memory
When the nuke plant is about to blow up, you don't want the alarm
task swapped out to disk!
This is just a quick list and I'm sure I've forgotten some things. There
are many other properties that are often desirable (distributed systems
facilities, multiprocessing, specialized development environments, etc.)
that may be desirable or necessary for any given application.
Maybe the overriding idea here is that the main difference between
real-time and non-real-time systems is not just speed (although that
is certainly important) but architecture.
OK. Let the flames begin.
--
Jerry Fiddler
Wind River Systems
{sun,rtech}!wrs!jerryscottg@hpiacla.HP.COM (Scott Gulland) (07/13/88)
> / hpiacla:comp.os.misc / stan@shell.com (Stan Hanks) / 10:18 am Jul 11, 1988 / > Just a quick question, while we're talking about realtime OS: > > what is the nominal interrupt dispatch time for Unix (time from the > the hardware interrupt line being yanked until your interrupt handler > is executing)? I can't remember that exact timing, but it is loooong. Something on the order of 2.0 milli-seconds on a totally quiescent system and 9.1 milli-seconds on a reasonable busy system. The averages are more like 0.8 and 1.3 milli-seconds respectively. Note that in real-time systems you should be asking for worst case rather than nominal. It does do much good if nine times out of ten that critical interrupt is handled just fine but on the tenth try you melted down your reactor because it took a hair too long to open a valve. These figures are for an HP9000/S840 running under HP-UX 2.0, a real-time Unix operating system. I am assumming that by interrupt handler you mean a user process for handling the interrupt. In this case the handler in these measurements is a real-time process which has the highest priority on the system. These measurements were taken using logic analyzers. ************************************************************************** * Scott Gulland | {ucbvax,hplabs}!hpda!hpiacla!scottg [UUCP] * * Indus. Appl. Center (IAC) | scottg@hpiacla [SMTP] * * Hewlett-Packard Co. | (408) 746-5498 [AT&T] * * 1266 Kifer Road | 1-746-5498 [HP-TELNET] * * Sunnyvale, CA 94086 USA | "What If..." [HP-TELEPATHY] * **************************************************************************
ward@cfa.harvard.EDU (Steve Ward) (07/14/88)
.... .... Many features and functions of realtime OS's have been put forth to describe what is a realtime OS. I have a few "peanut gallery" comments to add: I would be more rigid in stating that a realtime OS is predictable -- a realtime OS is totally deterministic by design. Indeed, this is the cornerstone of a realtime OS. This means for any given description of the current state of the machine/OS/application (state of the machine) it can be exactly determined what the machine function/action/timing will be (next machine state). I emphasize "determine exact timing." A realtime OS must be event driven and use preemptive task scheduling and allow full, direct, and "easy" use of interrupts, as has already been stated. Additionally, this must mean that interrupt support allows interrupt routine context switch activation. This means that not only must one be able to change process priorities from an interrupt routine and then request a context switch but the request for the context switch (or request to reschedule a process or however you want to describe it) must be immediately and predictably executed. Many "realtime" OS's will accept the context switch request but will wait until a future realtime clock timeslice to actually perform the task rescheduling. The interprocess communication mechanisms (signals, or whatever) should also be "reliable." It should not be possible to lose signals (or whatever the IPC method). Either the set/reset/arm protocol must be bulletproof, preventing the possibility of loss of signals by design of the protocol, or (or both) signals must be queued. In fact, any realtime communication mechanism must be guaranteed by design to be totally reliable. This is not needed (and not available!) for timeshare systems since if one signal generated by a character arrival is lost or not sent, not to worry, the next character in will generate a signal or its signal will be received. The application code is usually written to accomodate such "loose" signalling and the resultant "loose" timing is not an issue. (except when one is really trying to do realtime programming on UNIX :-) This is admittedly simplistic example, but it hopefully makes the point. Another galling point is the difficulty one often encounters in dealing with OS modes. The OS may purport to be realtime and do many desirable realtime things, but one finds out that many of the functions can only be used/invoked in protected OS or hardware machine modes. Further, it is common to find it difficult to use or invoke these modes. This is ridiculous. All realtime OS functions and machine modes should be easily manipulable by the realtime programmer. If doing this is complicated, arcane, or mystical, then the OS should include full libraries and certainly full documentation. In any case, the realtime programmer should not have to do what would otherwise be construed as system programming to do realtime programming. This philosophy should extend to all programming areas such as device drivers and interrupt handlers. For timeshare systems and users these ARE system (programming) functions, but for the realtime programmer these are USER APPLICATION programming functions. The realtime OS should make programming in these areas as simple and direct as most timeshare user programming interfaces/environments. As an aside, I personally feel that the true realtime engine is best implemented in hardware without paging/swapping MMU hardware. Simple memory protection-only schemes are fine, but virtual memory inflicts complication and unpredictability. If one must implement a realtime OS on hardware with an MMU, particularly with virtual memory, the realtime OS ought to turn the thing off and leave it off. If the MMU presence inflicts itself in any way on the hardware operation then there should be libraries to simply deal with any possible MMU interaction (ex. mapping hardware I/O registers into a process space at any chosen process/machine level such as user, kernel or whatever). Steven Ward Harvard-Smithsonian Observatory ward@cfa (BITNIT, UUCP) NASA SPAN: CFA3::SWARD .