vik@bobkat.UUCP (Vik Ram Sohal) (08/18/87)
Does anybody out there know anything about what kind of real-time Unix systems are available? (for things like automation, control, robotics, etc...). I would appreciate any pricing information you may have also. Thanks, Vik Sohal
richard@islenet.UUCP (Richard Foulk) (08/20/87)
In article <2663@bobkat.UUCP> vik@bobkat.UUCP (Vik Sohal) writes: > > Does anybody out there know anything about what kind of real-time > Unix systems are available? (for things like automation, > control, robotics, etc...). I would appreciate any pricing information > you may have also. > Why bother with real-time unix? Dedicate some smaller processors, to the heavily time-dependant stuff, and let the unix system oversee the operation. No sense getting mixed up with some funny/special version of unix if you don't have to. And if you connect things together in a reasonable way problems should be easier to diagnose, and you won't be tying yourself to one particular vendor. -- Richard Foulk ...{dual,vortex,ihnp4}!islenet!richard Honolulu, Hawaii
rick@leadsv.UUCP (Rick Schneider) (08/20/87)
In article <2663@bobkat.UUCP> vik@bobkat.UUCP (Vik Sohal) writes: > >Does anybody out there know anything about what kind of real-time >Unix systems are available? Real-time and Unix are, like army and intellegence, mutually exclusive terms! Unix is a time sharing system and in no stretch of the imagination can be "real-time". Gould CSD is working on a "real-time" unix as well as a "secure" unix. (I would think that "secure" is about as accurate a term as "real-time" in describing unix)
fred@rover.UUCP (Fred Christiansen) (08/20/87)
In article <2663@bobkat.UUCP> vik@bobkat.UUCP (Vik Sohal) writes: >Does anybody out there know anything about what kind of real-time >Unix systems are available? (for things like automation, >control, robotics, etc...). > Thanks, Vik Sohal there's Regulus from Alcyon in San Diego, Unos from Charles River Data, and something-whose-name-i-forget from Emerge Systems in Indialantic, Florida. Masscomp has RTX. and that's just some 680x0 ones that i'm aware of. -- Fred Christiansen ("Canajun, eh?") | seismo!noao!mcdsun!nud!fred (ARPA gate) Motorola Microcomputer Div., Tempe, AZ | utzoo!mnetor!mot!fred "The greatest thing a father can do for| ihnp4!mot!fred his children is to love their mother." | hplabs!motsj1!ellymae!fred
rml@hpfcdc.HP.COM (Bob Lenk) (08/21/87)
> Real-time and Unix are, like army and intellegence, mutually exclusive > terms! Unix is a time sharing system and in no stretch of the > imagination can be "real-time". This depends on your definition of "UNIX" or "real-time". Certainly you there are real-time tasks that can't be handled by the UNIX(r) system shipped by AT&T. On the other hand, there is no reason a system can't be built that has all the external appearance of "UNIX" and also handles real-time tasks. Certainly a system won't do a very good job of handling close to its hardware's capacity of both real-time and timesharing demands simultaneously, but that doesn't mean one can't do a good job with reasonable loads of each type separately and perhaps even with limited mixtures. > Gould CSD is working on a "real-time" unix as well as a "secure" > unix. Many vendors are working on or shipping both, and many customers are looking for or using both. Some such systems may not be very good at being "real-time", "secure", or "UNIX" by your definition or mine, but that doesn't mean that this is impossible. Bob Lenk (hpfcla!rml)
chris@mimsy.UUCP (Chris Torek) (08/21/87)
In article <1678@leadsv.UUCP> rick@leadsv.UUCP (Rick Schneider) writes: >Real-time and Unix are, like army and intellegence, mutually exclusive >terms! A base canard. Seriously, real-time and full-blown-operating-system have a tendency to be, at least, mutually combative, but like most operating systems, if you work at it, you can get Unix out of the way, too. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
hubcap@hubcap.UUCP (Mike S Marshall) (08/21/87)
In article <3138> rick@leadsv.uucp (Rick Schneider) writes:
*
*Real-time and Unix are ... mutually exclusive terms! Unix is a time sharing
*system and in no stretch of the imagination can be "real-time".
I disagree 100 percent. There is a page and a half of notations in the
1987 /usr/group Unix Products Directory under the heading "REAL TIME".
Masscomp, who makes (among other things) real time data acquisition
unix boxes, is one of the manufacturers listed. They supplied the real
time data acquisition equipment that was sent into space to monitor the
(Halleys?) comet fly-by.
-Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcaplarry@kitty.UUCP (Larry Lippman) (08/22/87)
In article <3438@islenet.UUCP>, richard@islenet.UUCP (Richard Foulk) writes: > > Does anybody out there know anything about what kind of real-time > > Unix systems are available? (for things like automation, > > control, robotics, etc...). > > Why bother with real-time unix? > > Dedicate some smaller processors, to the heavily time-dependant > stuff, and let the unix system oversee the operation. No sense > getting mixed up with some funny/special version of unix if you > don't have to. And if you connect things together in a reasonable > way problems should be easier to diagnose, and you won't be > tying yourself to one particular vendor. The above advice is _exactly_ some of what my organization does to apply standard Sys V UNIX versions to real-time applications. For example, for the past 3 years we have used 3B2's for scientific instruments and process control applications. We use slave processors - in many cases simple 8051-based devices - to acquire data, "time-stamp" it, and perform control functions. These slave processors all connect via high-speed serial lines. On the Intel Multibus machines (286-based, Intel 310/311) that we use we run standard Intel XENIX 3.4, and use slave processor boards to handle our external data acquisition and control functions. These slave processor boards communicate via DMA and have appropriate XENIX drivers. Intelligent and sometimes clever use of available UNIX functions can be used to achieve what I jokingly call "quasi" real-time performance. For example, use of system calls like plock(2), nice(2), along with appropriate use of ipc functions (semaphores and shared memory) can vastly improve performance of routines which are time-critical. I have looked at various real-time UNIX versions, and I do not care for them in OUR applications. Why? Because these real-time versions lack certain system calls and do NOT support many standard UNIX utilities. I feel that the usefulness of UNIX as a multi-user, multi-tasking system is that any user should be able to run what they want. This is simply not true on any real-time UNIX system that I have seen. For example, the last that I knew, there were NO real-time UNIX systems which would support `vi'. How can you have UNIX without `vi'? 1/2 :-) As a serious example, if I have a chemical process control system that is collecting data in real time, I feel that an engineer should be able to log into a terminal and run any spreadsheet or other program he wants with that data (at a lower priority, of course). But I don't know of any real-time UNIX that is not essentially bound to specifically compiled application programs, some language support, and a simple editor. <> Larry Lippman @ Recognition Research Corp., Clarence, New York <> UUCP: {allegra|ames|boulder|decvax|rutgers|watmath}!sunybcs!kitty!larry <> VOICE: 716/688-1231 {hplabs|ihnp4|mtune|seismo|utzoo}!/ <> FAX: 716/741-9635 {G1,G2,G3 modes} "Have you hugged your cat today?"
rich@oxtrap.UUCP (K. Richard Magill) (08/22/87)
In article <8050@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <1678@leadsv.UUCP> rick@leadsv.UUCP (Rick Schneider) writes: >>Real-time and Unix are, like army and intellegence, mutually exclusive >>terms! >A base canard. >Seriously, real-time and full-blown-operating-system have a tendency >to be, at least, mutually combative, but like most operating systems, >if you work at it, you can get Unix out of the way, too. I beg to differ. On our Sequent Balance 8000 (with 6 nsc32032's (@10Mhz)), I can lock a process on a processor and tell the scheduler to leave me alone. What can be more real-time? K. Richard Magill "lies keep people happy" - I94 west of detroit
gwyn@brl-smoke.UUCP (08/22/87)
In article <1951@kitty.UUCP> larry@kitty.UUCP (Larry Lippman) writes: >But I don't know >of any real-time UNIX that is not essentially bound to specifically >compiled application programs, some language support, and a simple editor. "Real-time" is a buzz word without a sufficiently precise meaning. Many years ago, I made some relatively small changes to 6th Edition UNIX to support memory-locked, preemptively-scheduled processes without doing damage to the normal mode of system operation. John Quarterman developed a high-throughput data acquisition scheme using double-buffering in a user-mode process pair that took advantage of the features I just mentioned, combined with an appropriate device driver. A small amount of hardware FIFO buffering on the input channels really helped. And of course, for highest throughput we would write the data to raw disk. I think our system qualified as "real-time", whatever that term is supposed to mean. Sure, we had to write some code, but no more than we would have had to do for any operating system. I've read claims that UNIX is no good for "real-time" computing for many years, and my impression is that that myth spread from the collection of lies, half-truths, and misrepresentations that were introduced in the ARPA VMS-vs-UNIX debate back when the standard ARPAnet host was being changed from a DECsystem-20 to a VAX. (There was one famous article in particular, but I forget the author's name. For a couple of years one kept encountering obvious parroting of that article.) Now it probably IS true that one would have to work harder to use (for example) 4.3BSD as the basis of a real-time application like the data acquistion one I described. That's simply because the system has gotten a lot more complex over the years (with addition of virtual memory, network protocols, etc.), so ensuring a suitable operating environment for real-time processes is harder. The main key to getting decent real-time performance out of any UNIX variant (while not hurting its normal operation) is to make sure its scheduler offers suitable support. Most UNIX schedulers I've encountered so far need work in that area (sorry, Ken).
chris@mimsy.UUCP (Chris Torek) (08/22/87)
>In article <8050@mimsy.UUCP> I claimed: >>... like most operating systems, if you work at it, you can get Unix >>out of the way, too. In article <318@oxtrap.UUCP> rich@oxtrap.UUCP (K. Richard Magill) writes: >On our Sequent Balance 8000 (with 6 nsc32032's (@10Mhz)), I can lock a >process on a processor and tell the scheduler to leave me alone. What >can be more real-time? What do you think `lock[ing] a process on a processor and tell[ing] the scheduler to leave [it] alone' is doing? This took quite a bit of work. Fortunately, Sequent has already done most of it. Masscomp also provides Unix systems with most of the work done already, and I am sure there are other vendors who have managed to `get Unix out of the way' too. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
decot@hpisod2.HP.COM (Dave Decot) (08/23/87)
> I have looked at various real-time UNIX versions, and I do not > care for them in OUR applications. Why? Because these real-time versions > lack certain system calls and do NOT support many standard UNIX utilities. > I feel that the usefulness of UNIX as a multi-user, multi-tasking system > is that any user should be able to run what they want. This is simply > not true on any real-time UNIX system that I have seen. For example, > the last that I knew, there were NO real-time UNIX systems which would > support `vi'. How can you have UNIX without `vi'? 1/2 :-) All HP-UX systems support all SVID2 base system calls, many 4.2BSD system calls, and `vi', since HP-UX is SVID Version 2 conforming. In addition to the real-time features I described in an earlier response, the new HP 9000/800 systems support sendmail, 4.2BSD job control and signals, System V accounting, shell layers, X windows, SQL, IMAGE, the ARPA/Berkeley networking facilities, and much more. Various versions of Emacs are available as contributed software. > As a serious example, if I have a chemical process control system > that is collecting data in real time, I feel that an engineer should be > able to log into a terminal and run any spreadsheet or other program he > wants with that data (at a lower priority, of course). But I don't know > of any real-time UNIX that is not essentially bound to specifically > compiled application programs, some language support, and a simple editor. The example you describe is easy on HP-UX (assuming chemctrl is properly programmed, locks itself in memory, uses O_NDELAY on appropriate files, etc.): prealloc 10000000000 /tmp/chem # reserve 10 Gigabytes fast file space rtprio 4 chemctrl > /tmp/chem & # run chemctrl with realtime priority 4 chemthink /tmp/foo > chem.123 # run data munger at timeshare priority lotus123 chem.123 # run spreadsheet at timeshare priority Disclaimer: Information purposes only. Not a product offering/advertisement. I believe this stuff to be correct, but if there's money involved, ask a local HP representative. Dave Decot Hewlett-Packard hpda!decot
berger@datacube.UUCP (08/24/87)
We have implemented a scheme where we control our "real time" image
processing hardware with a Sun Workstation. It has to handle at
least 60Hz frame rate interrupts to dynamically update the registers
of our image processing hardware. We did this by creating a
"programmable" interrupt handler. Our user program can send down
instructions to the driver to tell it what to do when it gets certain
interrupts.
This was very specific for our hardware but it works very well. What
I'd like to see in terms of evolution of Unix would be some ability
to create a unix kernel / utility package that is tuned for an
application. IE the ability to select features, options and
utilities and then build a dedicated version with just those things.
Thus you could create embeded applications with just the amount of
baggage you need.
The major goal of this is to have a target kernel that could possibly
be prommed and yet the programmer can expect a c runtime / system
environment that they are pretty used to.
For PROM based embedded systems, we are currently using OS-9 in such
a way, we mostly edit, cross-compile on our Unix systems and download
to our OS-9 systems. OS-9 has some features that would be nice in a
targetable "Unix" such as shareable libraries that link with the
executables at run-time, executables and the operating system itself
is promable, does not require an MMU, etc. Once we have debugged the
software, we can burn it into PROM.
We've made OS-9 look as much as possilbe as a unix run time
environment. Ideally we could be cross compiling to an environment
that had a POSIX compatable run time environment that maybe had a few
restrictions to allow it to be prommed and not require an MMU.
It would also be nice to be able to attach interrupts to user code
and a standard way to map physical addresses into user space.
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerkai@ihlpa.ATT.COM (Irwin) (08/24/87)
In article <3138> rick@leadsv.uucp (Rick Schneider) writes: > > Real-time and Unix are ... mutually exclusive terms! Unix is a time sharing > system and in no stretch of the imagination can be "real-time". Unix rtr (formally DMERT) is a realtime unix system designed to run on a 3B20 Duplex processor. It is a telco controller and has been in use since "Bell System" days. If you make a long distance call though AT&T it is more than likely being routed by a real time Unix system, as well as several million lines handled by the BOCS. UNIX is regesterd trade mark of AT&T AT&T stands for American Telephone and Telegraph telephone switches REQUIRE real time operating systems given the above three statments (all common knowlege in the industry, or at least to 90% of the users of the net) you can pretty much assume there is a real time unix somewhere within AT&T, Think Rick! Ken A. Irwin AT&T Bell Labs, Naperville (you know the place were they develop real time unix telephone switches?) IHP 1A332 (312) 416-4485
inra@axis.fr (Inst. Natl. Rech. Agronomique) (09/02/87)
Does anyone have a driver for the laser printer Canon LBP8II? Thanks in advance