daryl@mitre.arpa (08/24/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. >>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. The something-whose-name-was-forgotten is RTUX. They would thank you for at least remembering the company name. RTUX runs real-time processes on the native UNIX CPU at higher priority than UNIX processes. Facilities are available to communicate with UNIX processes and to communicate with other independent real-time processors equipped with RTUX executives not using UNIX. This technique permits UNIX to be used as the development tool, operator interface, and mass storage handler, but also permits the UNIX native CPU to process real-time data without being burdened by the UNIX task switching overhead. Where bus bandwidth is a problem, use multiple bus architectures and additional real-time single board processors equipped with the RTUX stand-alone executive to share the task load. General Motors (GMF) Robotics, Troy Michigan is a big customer. Address inquiries to Frank Aaron, EMERGE Systems, 114 6th Ave. P.O., Box 3175, Indialantic, Florida 32903 (305) 723-0444. Mention my name. Another avenue to investigate is the suite pSOS, pROBE, pHILE, pRISM, and pUCP. pSOS is a multitasking kernal for single board computers. pROBE is a low level debugger. pHILE is disk file management system similar to UNIX's. pRISM adds multiprocessor capability to pSOS. pUCP adds ability to communicate between the UNIX system and other processors running pSOS. Also, pUCP permits pSOS to be emulated on the UNIX system. Although pSOS is not an efficient real-time solution on UNIX alone, it does permit marrying a UNIX system and external real-time processors. The suite is made by Software Components Group, Inc., 4655 Old Ironsides Drive, Santa Clara, CA. 95054. Contact Linda Munz, (408)-727-0707. Mention my name. D.A.R.Y.L. Daryl Crandall daryl@dash.mitre.ORG The MITRE Corporation daryl@gateway.mitre.ORG 7525 Colshire Dr. daryl@mitre-gateway.ARPA Mail Stop Z425 McLean, VA 22102 NOTE: 1st form of address is prefered (703) 883-7278 for people with MX sendmail.
jbm@aurora.UUCP (Jeffrey Mulligan) (08/25/87)
We are running a real-time system that noone has mentioned yet; it is called VENIX, and is sold by a company called Venturcom, which is located in Massachusetts. We run it on a PDP-11/73, but they support a variety of machines. There are a variety of additional system calls: nice(-100) hog cpu phys(...) map I/O page (for instance) into user space This system is OK, but there are a few bugs. In my previous lab, we ran an old version 6 kernel (on an 11/23) which had an enhancement (from Berkeley?) in the form of an rtp() system call (real-time process). This basically inhibited swapping. As we had kernel source, I was also able to do some things like squelch lightning bolt clock interrupts. I must admit I was never interested in running a spreadsheet while doing a realtime task. We did sometimes run experiments with a second user editing at the same time, but the performance for the second user was pretty poor. I also had some experience with a Bell Labs in-house hack which provided features similar to VENIX, i.e. mapping the I/O page into user space. Another interesting feature it had was that you could set device interrupts to trap to user space routines. -- Jeff Mulligan (jbm@ames-aurora.arpa) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-5150
pf@diab.UUCP (08/26/87)
In need of a Real-Time unix compatible os. ( SYSV.2 SVID compatible, handling trap queues an asyncrhonus events). Make a call to : Diab Systems inc. 323 Vintage Park Drive Foster City, CA 94404. They might be abel to help you.
dupont (Pierre Dupont) (10/04/90)
I would like to know of any real-time Unix implementations that are System V compatible and claim to conform to the POSIX 1003.1 and 1003.4 standards. Any information such as the hardware platforms it runs on and any first-hand experience with the product would be appreciated.
mbrown@tonic.osf.org (Mark Brown) (10/04/90)
In article <1990Oct3.171822.18380@mdivax1.uucp>, writes: |> I would like to know of any real-time Unix implementations that are |> System V compatible and claim to conform to the POSIX 1003.1 and 1003.4 |> standards. Any information such as the hardware platforms it runs on and |> any first-hand experience with the product would be appreciated. This is gonna be kind of tough, considering that 1003.4 isn't a standard yet (hence, no one can "conform")... Mark Brown IBM AWD / OSF |"Coffee for my breakfast, whiskey by the side The Good mbrown@osf.org | it's a dark and gloomy mornin', The Bad uunet!osf!mbrown| gonna rain outside, outside --- The Ugly (617) 621-8981 | ...and the forecast calls for pain."
gt0178a@prism.gatech.EDU (Jim Burns) (10/04/90)
in article <1990Oct3.171822.18380@mdivax1.uucp>, says: > I would like to know of any real-time Unix implementations that are > System V compatible and claim to conform to the POSIX 1003.1 and 1003.4 Add HP-UX to your list. It's SVID, and 1003.1 (don't know about 1003.4). > standards. Any information such as the hardware platforms it runs on and HP 9000/300 & 800 > any first-hand experience with the product would be appreciated. Like what? I use mostly IPC's, not real-time priorities (implemented as 0-127, w/*no* automatic nicing for long running procs.) The 800 is definitely a peppy system, and IMHO is one of the better combination BSD/SysV implementations. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
amen@SGI.COM (Bob Amen) (10/09/90)
From article <1990Oct3.171822.18380@mdivax1.uucp>, by <somebody>: + I would like to know of any real-time Unix implementations that are + System V compatible and claim to conform to the POSIX 1003.1 and 1003.4 + standards. Any information such as the hardware platforms it runs on and + any first-hand experience with the product would be appreciated. Silicon Graphics version of Unix (IRIX) has guarenteed interrupt response (time from receipt of interrupt to 1st line of user code) of 1.3 millisec. It is SVID compliant and is POSIX 1003.1 compatable. We are working on full POSIX compliance which should be achieved by the next release of IRIX (shceduled for sometime Q1 CY91). When P1003.4 is decided on SGI will implement the standards. -- Bob Amen (amen@sgi.com) (+1 213 312-0227) Silicon Graphics Computer Systems -- Los Angeles Office