aglew@urbsdc.Urbana.Gould.COM (06/25/88)
..> Real Time UNIX
Gould UTX 32 2.1 on Powernodes (our old line) has a number
of Real Time UNIX features - our former project scientist,
John Gertwagen, was head of the IEEE subcommittee on RT UNIX
for a while (hi John!). Off the top of my head, we have:
(Hold on. First, I should mention that our new NP processor
line, NP, has many of these real time features, and others,
but I'm not so close to that project. Second, I'm not a
marketing guy, so I may have made mistakes in this list.
Finally, I'm not a marketing guy, even though I have made a lot
of Gould booster posts recently. I apologize to the net for
excess enthusiasm, but I think Real Time UNIX, from Gould,
other companies, or from the IEEE committee, is an idea that
has been needed for a while).
- real time scheduler
letting you guarantee that a process will run
before any other (fixed priority) and will only
run on a specific processor (processor targetting)
(by default our dual processors load balance)
- suspend/resume
direct control over process context switch - so you can
say "suspend me and start this process running immediately".
Much faster than signals.
- cyclic scheduler
a low overhead way of setting up process groups
that run repeatedly, in a specified phase relationship
to each other - flight simulator people use it.
- high resolution timers and timeouts (600 ns accuracy)
- directly connected interrupts
let an (appropriately priviliged) user process handle
device interrupts directly
- indirectly connected interrupts
arrange for an arbitrary device interrupt to send a
signal to a process (which is typically running with
RT priority to handle the interrupt fast)
- hardware privilige mode
let the (appropriately priviliged) user execute any instruction
instruction he wants, including those normally denied to users.
Those, you can do anything the machine can do - but still have
the convenience of calling UNIX services.
- prepage and lockdown
- memory classes
Gould processors support several different types of memory:
normal cached memory; "shadow memory" - cache speed SRAM;
"reflective memory" - memory that is shared between multiple
processors (over and above the normal dual processor);
address ranges for I/O, etc.
We have routines that let you handle all this.
- Direct I/O
Gould PN's have an intelligent I/O system - this is a driver
that makes it easier to write your own I/O command chains.
- Direct File System
a contiguous file system
- IPC
BSD and System V (messages, semaphores, etc.) IPC.
Most importantly, shared memory, between processes on the same
system, on different processors of the standard dual processor
configuration, or (using reflective memory, etc.) between
different systems.
> I'm told that HP/UX has some of this, but I haven't seen it
>demonstrated, while the Venturcom people gave an impressive demo to the
>Upstate NY UNIX Users Group.
> bill davidsen (wedu@ge-crd.arpa)
Can you describe what a good demo of Real Time UNIX should be?
Honestly, we've had a bit of trouble coming up with a demo.
Our customers use it for flight simulation and telemetry, not
exactly the sorts of things that you put into a show.
And, it's not very impressive to start processes running, and say
"look, it priority preempted!". Maybe some neat graphics, showing
unreliable performance without RT, and reliable performance with.
Hmm.
Finally, may I say that Real Time UNIX features are useful for
more than Real Time applications? For example, fixed priority
scheduling - there have been many times that I wanted to have
a "deep background" application, that would run only when the
system is otherwise idle. No matter how much you nice, your
process will still take some cycles away when the system isn't
idle. Hell, I got interested in RT UNIX way back in school
- gawk, that's 7 years ago now! - when I tried to write a
keyboard program that timed keystrokes on a UNIX machine...
Not to mention the needs of a lab computer...
Real Time UNIX is an idea whose time has come.
*All* UNIXes should be Real Time.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have MX records
aglew@xenurus.gould.com - if you don't
...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.aglew@urbsdc.Urbana.Gould.COM (06/25/88)
>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. Sure, I agree - all the other Real Time features are just there to provide support for the scheduler. Fast I/O, prepaging... Of course, the fact that I did our RT scheduler, and that I love all types of scheduling problems, might colour my attitude a little bit... Ahh, scheduling: time sharing, fair-sharing, fixed priority, deadline driven, feasibility... it's wonderful stuff! By the way, has anyone commercially implemented a deadline driven scheduler? And, can anyone who has worked on (preferably managed) an AT&T system with the fair share scheduler share their experiences with me (by mail, address below)? Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have MX records aglew@xenurus.gould.com - if you don't ...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.
rick@vsi1.UUCP (Rick Schneider) (06/29/88)
From article <29500025@urbsdc>, by aglew@urbsdc.Urbana.Gould.COM: > > ..> Real Time UNIX > > Gould UTX 32 2.1 on Powernodes ... The only problem with GOULD's RT-UNIX is that it is only intended to run on GOULD machines. If GOULD is planning to port UTX/32-RT to other platforms, its news to me. -- Rick Schneider ...pyramid!vsi1!rick VICOM SYSTEMS, INC.; 2520 Junction Avenue, San Jose, Ca, 95134, (408) 432-8660 The opinions expressed are not those of my employer or are they?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/30/88)
In article <745@vsi1.UUCP> rick@vsi1.UUCP (Rick Schneider) writes: >The only problem with GOULD's RT-UNIX is that it is only intended to >run on GOULD machines. Does this somehow surprise you? What IS your point?
rick@vsi1.UUCP (Rick Schneider) (06/30/88)
From article <8188@brl-smoke.ARPA>, by gwyn@brl-smoke.ARPA (Doug Gwyn ): > In article <745@vsi1.UUCP> rick@vsi1.UUCP (Rick Schneider) writes: >>The only problem with GOULD's RT-UNIX is that it is only intended to >>run on GOULD machines. > > Does this somehow surprise you? What IS your point? The point is that if you want GOULD's RT-UNIX, you'll have to buy a GOULD Powernode or NP series machine to run it on. GOULD has in the past sold source licenses for all of its flavors of UNIX, so I guess that the source for it RT-UNIX will also be available. If you have a large budget and like hacking the kernal, buy a low-end Powernode with a UTX/32-RT source license, and port it wherever you would like. I worked for GOULD-CSD for several years and from my experience, their implementations have been excellent, support is above average, and pricing is in line with the rest of the industry. -- Rick Schneider ...pyramid!vsi1!rick VICOM SYSTEMS, INC.; 2520 Junction Avenue, San Jose, Ca, 95134, (408) 432-8660 The opinions expressed are not those of my employer or are they?
aglew@urbsdc.Urbana.Gould.COM (07/01/88)
>The only problem with GOULD's RT-UNIX is that it is only intended to >run on GOULD machines. If GOULD is planning to port UTX/32-RT to other >platforms, its news to me. Well, actually, many of the features we were hoping to propose for standardization -- hence our participation in the POSIX committees (similarly for Secure UNIX). Unfortunately, the RT committee got bogged down in ideological questions, many of them put by large computer companies that did not have RT features in their UNIX. Were they trying to delay a RT standard? Nahh... I've lost track of the RT committee recently, but hear they may be making progress. I'm waiting for the day. We may have to make some changes to conform to the standard, but they won't be too hard. Real-Time UNIX is an idea whose time has come.