walden@dip.eecs.umich.edu (Eugene Marvin Walden) (07/19/90)
I was wondering if anybody knows of any other commercial real-time operating
systems than the ones listed below:
1. VRTX (Ready Systems)
2. IRMX (Intel)
3. QNX (Quantum Software)
4. VxWorks (Wind River Systems)
5. OS/9, OS/9000 (Microware)
6. Alpha (Concurrent Computer Corp.)
7. Kadak
All of the above except #6 (Alpha) are really not true real-time operating
systems, because there is no provision for handling deadlines. The Alpha op-
erating system is state-of-the-art, but I don't know anything about its avail-
ability.
So here's the question-- anybody have any other RTOSs that they know of? I
am particularly interested in a system that has something more sophisticated
than a simple priority-based scheduler, but any other additions would be use-
ful as well.
- Thanks a bunch
Eugene Walden (walden@dip.eecs.umich.edu)jlaurent@encore.com (Jim Laurent) (07/20/90)
From article <2931@zipeecs.umich.edu>, by walden@dip.eecs.umich.edu (Eugene Marvin Walden): > > I was wondering if anybody knows of any other commercial real-time operating > systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 5. OS/9, OS/9000 (Microware) > 6. Alpha (Concurrent Computer Corp.) > 7. Kadak > Encore Computer Corporation has announced the introduction of a new system called the Series 91 The Encore 91 supports 2 or 4 88k CPUs on a board with 8 88200s. Full shared memory multiprocessing is supported. Software consists of UMAX V OS along with Encore's MicroMPX RT OS. Full multithreading and parallel processing are supported in the Unix or real-time environments. Programming interface will be POSIX 1003.4 compliant. MicroMPX is based on Encore's (aka Gould/SEL) MPX-32 Real-time OS for its proprietary Concept/32 CPUs. Also on the board are 2 SCSI ports, Ethernet, real-time clocks and interrupts, 16 MB RAM and 4 RS232 ports. The single 9U board plugs into a VME chassis. Expansion memory, Encore HSD controllers and Encore's Reflective Memory are available. Jim Laurent UUCP: uunet!gould!jlaurent Greenbelt, MD Sales Office INTERNET: jlaurent@encore.com Encore Computer Corporation
swoyer@masscomp.ccur.com (Ted Swoyer) (07/20/90)
In article <2931@zipeecs.umich.edu> walden@dip.eecs.umich.edu (Eugene Marvin Walden) writes: > > I was wondering if anybody knows of any other commercial real-time operating >systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 5. OS/9, OS/9000 (Microware) > 6. Alpha (Concurrent Computer Corp.) > 7. Kadak > > All of the above except #6 (Alpha) are really not true real-time operating >systems, because there is no provision for handling deadlines. The Alpha op- >erating system is state-of-the-art, but I don't know anything about its avail- >ability. > So here's the question-- anybody have any other RTOSs that they know of? I >am particularly interested in a system that has something more sophisticated >than a simple priority-based scheduler, but any other additions would be use- >ful as well. > You missed Concurrent Computer Corp.'s RTU operating system. RTU is a System V Release 3 compliant operating system with extensive enhancements to support real time applications. RTU also provides a 4.2BSD compatibilty environment for easy porting of Berkeley based applications. RTU is available on Concurrent's line of multiprocessors including a Motorola 68020 platform, a Motorola 68030 platform and a MIPS R3000 platform. RTU's enhancements are in the following domains: Multiprocessing RTU supports symmetric multiprocessing, threads and compilers enhanced to provide parallelization. RTU also supports directed interrupt handling to free up all but the boot processor from handling interrupts (normally interrupts are symmetricly handled), distribution of interrupts so specific CPUs can process specific interrupts or interrupt levels, automatic process scheduling among time-sharing processors from a single run queue, user control over the processors on which processes may run (at run time or shell command execution) (all, several or one - with a choice of which one(s)) and a real-time slave environment which essentially dedicates the slave processor(s) to an interrupt source in bare metal (but with system services standing by). Preemption RTU supports process preemption in both kernel and user space, allowing higher priority tasks to run as soon as they are ready even if a lower priority process is executing a system call. Scheduling In addition to the standard UNIX scheduling policy, RTU supports a fixed priority policy and a fixed priority with quantum policy (round robin with fixed priority). The next version of RTU will include a synthetic period scheduler (capable of synthesizing an execution pattern synchronous to a given frequency). Memory management RTU supports locking a either all or part of a process into memory. Either text, data or both can be locked in using the System V block(2) system call or individual pages of text, data or stack can be locked using an RTU system call. A process with locked pages will not swap. Interprocess communication and synchronization RTU supports an Asynchronous System Trap mechanism for kernel to user or user to user communication. ASTs can be assigned different priorities, can pass information from the sending to receiving process, are queued, are serviced by priority order (32K priorities) and will never be lost. RTU also supports the System V shared memroy, semaphores, message queues, named pipes, memory based pipes, STREAMS and signals and BSD sockets and signals. In addition, RTU supports reserved memory to allow direct, unmediated communication between user address space and devices on the system bus. Reserved memory can also serve as a contiguous shared memory area. I/O In addition to the standard UNIX I/O mechanisms, RTU supports asynchronous I/O, I/O bus addressing, direct DMA to and from user space, synchronized I/O, multiple I/O buses, contiguous disk files, bit mapped disk allocation, preallocated files, direct I/O which bypasses the UNIX block buffering, exclusive disk operation and support for symmetric device driver. In the next release RTU will support disk mirroring, disk striping and disk dual porting. Deterministic response RTU essentially allows successive redirection of processing until what is left is just the process tied to just the interrupt or interrupt level running on 1-7 processors with direct access to the disk subsystem. This environment is called the real-time slave environment. All system services are also availabe in this environment, but process dispatch latencies will differ depending on the system services in use. If you want further information about RTU or Concurrent, contact me at (508) 392-2690. Ted Swoyer
hulsebos@ehvie0.tq.ine.philips.nl (rob hulsebos) (07/20/90)
In article <2931@zipeecs.umich.edu> walden@dip.eecs.umich.edu (Eugene Marvin Walden) writes: > I was wondering if anybody knows of any other commercial real-time operating >systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 5. OS/9, OS/9000 (Microware) > 6. Alpha (Concurrent Computer Corp.) > 7. Kadak > So here's the question-- anybody have any other RTOSs that they know of? 8. ERM (Philips) 9. MTOS 10. VMEexec (Philips, Motorola) ------------------------------------------------------------------------------- Rob Hulsebos == hulsebos@tq.ine.philips.nl Tel +31-40-785723, Fax +31-40-786114
vik@lynx.uucp (Vikram Sohal) (07/21/90)
In article <2931@zipeecs.umich.edu> walden@dip.eecs.umich.edu (Eugene Marvin Walden) writes: > > I was wondering if anybody knows of any other commercial real-time operating > > (list of real-time OSs deleted) > >systems, because there is no provision for handling deadlines. The Alpha op- > > Eugene Walden (walden@dip.eecs.umich.edu) We have a real-time UNIX-compatible OS called LynxOS that has a number of features you might find interesting, here are some of them: - We are implementing a rate-monotonic deadline scheduler for NASA (we were chosen by IBM as the operating system on space station FREEDOM project and are in the process of adding a number of these types of features to our standard product) - A real-time ADA interface (again for space station) - User-level threads (once again, for space station) - High speed contiguous files - reliable signals - complete compatiblity with System V, BSD 4.3, and POSIX 1003.1 (this allows us run NFS, X-Windows, MOTIF, etc) - High performance real-time response: 450 microseconds on a 20 MHz 386 AT with 2 waitstate RAM. - Multi-threaded, preemptive, reentrant, kernel (contains no AT&T code) - ROMability Currently LynxOS is available on the 80386, 68030, R3000, R6000, 88000, with ports to i860 under way . ----------------------------------------------------------------------------- Regards, Vic Sohal -----------------------------------------------------------------------------
krueger@notbad.enet.dec.com (07/21/90)
> > I was wondering if anybody knows of any other commercial real-time operating > systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 5. OS/9, OS/9000 (Microware) > 6. Alpha (Concurrent Computer Corp.) > 7. Kadak > Here is another VAXELN for realtime on a VAX. VAXELN Toolkit, Version 4.1 DESCRIPTION The VAXELN Toolkit is a VMS layered product used for the development of dedicated realtime VAXELN systems that run on VAX and MicroVAX processors. The development tools run on any host VAX computer under VMS or MicroVMS Operating Systems. A finished VAXELN system runs directly on a supported runtime target VAX or MicroVAX processor without the presence of another operating system. VAXELN is especially suited to, although not limited to, creating realtime applications; that is, applications in which the system's response (both speed and predictability) to external events is critical. The VAXELN software simplifies the design and implementation of such applications by offering high-level language support, a runtime kernel executive and various service programs. The high level language support includes a Pascal compiler and runtime libraries (RTL) for VAX C and VAX FORTRAN. Support for VAX Ada is available under separate license. The kernel manages resources, processes and shared data. The runtime service programs available are for a VMS compatible file system, network communication facilities and device drivers. VAXELN supports multi-tasking; that is, execution of a program made up of several concurrently executing parts. In addition, multiprogramming is supported, meaning that entire programs, including multi-tasking programs, can be scheduled concurrently on the same CPU. VAXELN provides support for tightly coupled symmetric multi-processing on the VAX 6000 Model Series 200, 300 and 400, and VAX 8800 configurations. Each processor executes a single copy of the system image and jobs can run on either processor. VAXELN DECwindows is based on M.I.T.'s specification for the X Window TM System, Version 11, Release 3. X Window System standards supported as part of DECwindows include the X11 network protocol, a base set of workstation fonts, the C language binding for the Xlib programming library and the C language binding for the Xtoolkit library. Support of the X11 network protocol in the client, library and display server components provides VAXELN with the capability to interoperate with other X11-compliant systems in a distributed fashion. VAXELN supports the server-client distribution inherent in the X Window System with three VAXELN-provided transports - local shared memory and DECnet. VAXELN DECwindows provides full client/server functionality. Provided are the DECwindows server image, the DECwindows runtime libraries and the user environment component DECwindows software, all of which can be built into VAXELN systems. X Window is a trademark of Massachusetts Institute of Technology. UNIX is a registered trademark of American Telephone and Telegraph Co. VAXELN Systems VAXELN systems can run on stand-alone VAX and MicroVAX computers or, with networking software provided in the Toolkit, they can be connected in an Ethernet local area network (LAN). The latter may include VMS nodes or any other nodes using the Digital Network Architecture DECnet services and protocols. VAXELN systems, including device drivers, can be developed entirely in a high-level language. The sources for several Digital implemented device drivers are also included. These can be used as a guide to implementing additional drivers. A VAXELN system can be booted from a hard disk, tape, diskette, or, if the VMS host system has the optional DECnet-VAX license and Ethernet hardware, by downline loading the system into the target computer. VAXELN system images are also suitable for placement in erasable programmable read-only memories (EPROMs). However, the EPROM hardware and software are not part of the Toolkit and must be acquired separately. Toolkit Components o VAXELN Pascal Compiler o VAXELN Symbolic Debugger o VAXELN System Builder o VAXELN Kernels for Supported Target VAX CPUs o VAXELN Pascal Runtime Library o VAXELN C Runtime Library o VAXELN FORTRAN Runtime Library o VAXELN Device Drivers for Supported Devices o VAXELN File Service o VAXELN Network Service o VAXELN Authorization Service o VAXELN Performance Analyzer o VAXELN Resource Monitor and Display o VAXELN Command Language o VAXELN Error Logging Utilities o VAXELN Local Area Terminal (LAT) Service o VAXELN DECwindows Server o VAXELN DECwindows User Environment Components o VAXELN User Documentation A VAXELN application image executes in its own runtime environment. Programs written to take advantage of VMS or ULTRIX system-specific features (i.e., logical names, QIO, RMS) need to be modified in order to be ported to the VAXELN Runtime environment. The VAXELN Pascal language is based upon the ANSI/IEEE770X3.97-1983, American National Standard Pascal Computer Programming Language. It is supported by an optimizing compiler that generates position-independent, native-mode code. The Pascal language was extended to allow its use for VAXELN system programming, and to eliminate the need to use assembly language for VAXELN system programming. The VAXELN C Runtime Library implements the standard features of the C language plus VAXELN-specific capabilities designed to assist the C program developer in taking full advantage of VAXELN. Routines selected for inclusion in this library are primarily those for which an efficient emulation of standard UNIX C is possible under VAXELN. VAXELN C uses the standard VMS C compiler. The VAXELN FORTRAN Runtime Library supports an extensive subset of the features of the standard VAX FORTRAN language. This library supports I/O to sequential devices and sequential and direct access to sequential files on mass storage media. The routines in this library also allow the FORTRAN programmer to access kernel services for developing realtime, multiprogram-ming applications. Since FORTRAN does not generate re-entrant code, care must be exercised to avoid multiple concurrent threads executing through subroutines and/or functions. That is, VAX FORTRAN subroutines and/or functions are serially reusable, but not re-entrant. User code is linked to VAXELN Runtime Libraries using the standard VMS linker. The libraries are provided in both object-library and shareable-image form. The VAXELN System Builder combines program images, the VAXELN kernel image, and runtime routines to produce the finished VAXELN system. The program loader permits dynamic loading of individual program images. The VAXELN Debugger can be used to debug a VAXELN system locally using the target system's console terminal. If the user's host system has the optional DECnet-VAX license, it can be used remotely to debug VAXELN systems running on the same DECnet Ethernet network. The VAXELN Kernel manages the system's processes and data, providing the controlled sharing of the system's resources. VAXELN systems are memory resident utilizing VAX virtual memory hardware. The VAX page fault mechanism is used only for dynamic extension of the user stack. A VAXELN system is limited in size by the amount of physical memory present on the target system. The VAXELN File Service is a set of services to enable using disk or tape files for program I/O. The File Service consists of a Disk File Service and a separate Tape File Service. The Disk File Service uses the same Files-11 on-disk structure, ODS-2, as does VMS and the same internal data format as the VAX Record Management Services (RMS). Consequently, disk volumes can be read or written from one environment to another. File Service files are sequentially organized but can be accessed either sequentially or randomly. The indexed and relative file organizations are not supported by VAXELN. VAXELN systems and VMS systems running on nodes in the same network can access files on each other's disk volumes. The Tape File Service is based on Version 3 of the ANSI standard for magnetic tapes. It is compatible with the VMS, Version 4.0 tape file system, providing users with a convenient means of transporting files to and from VMS systems. The VAXELN Network Service is responsible for providing transparent network message transmissions between CSMA/CD LAN (Ethernet/IEEE802.3) nodes. The Network Service uses the Phase IV DECnet Routing Protocol, Version 2.0, to route system-level datagrams between VAXELN nodes and other DECnet nodes. (Only end-node functionality is provided). The VAXELN system can communicate over the CSMA/CD LAN with any DECnet node on the same LAN. If there is a full routing system on the LAN, VAXELN can communicate with any other DECnet node in the entire network. The VAXELN CSMA/CD LAN driver will support multiple controllers of the same type simultaneously. At any given time, DECnet can run on only one controller. Other CSMA/CD LAN protocols can be implemented on the other controllers. VAXELN supports the dynamic enabling and disabling of DECnet. In the event of hardware failure, this feature can be used to dynamically disable DECnet on one controller, followed by enabling DECnet on another controller. Downline loading over the CSMA/CD LAN of a VAXELN system image, from a VAXELN load host to a VAXELN target, is supported. The Phase IV DECnet Network Services Protocol (NSP), Version 4.0 and the Session Control Protocol, Version 1.0 are used to provide transparent application-level circuits with remote nodes. The Network Service's NSP module then uses the Routing Protocol to deliver messages to remote systems. VAXELN DECnet nodes can be managed from VMS with the DECnet-VAX Network Control Program (NCP). The Network Service supports the Phase IV Network Management Protocol, Version 4.0 Subset. VAXELN supports industry standard networking through a set of ARPANET protocols. The supported protocols include: Transmission Control Protocol (TCP), Internet Protocol (IP), Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP), User Datagram Protocol (UDP) and Boot Protocol (BOOTP). This support is provided over a CSMA/CD LAN (Ethernet) and it interoperates with ULTRIX, VMS/ULTRIX Connection and UNIX. C Language applications and may be written using the Berkeley Socket Programming interface. The optional VAXELN Authorization Service maintains a database of all the users authorized to use a particular VAXELN system or network of systems and is compatible with standard, FILES-11 protection and security features. In conjunction with the VMS Error Log Utility, optional error logging is supported. The error log file can be created locally on the target system or created remotely on a VMS node in the network. The error log file is analyzed on a VMS system using the VMS Error Reporting Facility. VAXELN Command Language (ECL) provides commands to communicate with the VAXELN system. VAXELN ECL provides file manipulation, program manipulation and limited system control functions on the VAXELN system. VAXELN Resource Monitor (EDisplay) dynamically displays information about the VAXELN system. This information includes pool and memory usage, and currently active jobs and processes. Help feature functionality is included. VAXELN Performance Analyzer (EPA) provides collection of information and analysis of the runtime behavior of the VAXELN system. The information is subsequently analyzed on a VMS host. Local area transport (LAT) host services allow VAXELN targets to communicate with devices attached to terminal servers. These services include terminal server communication, terminal I/O, and a control interface for application programs plus an interactive utility, which can be used to control and monitor a LAT environment. The VAXELN DECwindows Server provides a common means for DECwindows applications to interact with graphics workstations. The DECwindows server image runs as a job on the hardware where the display, keyboard and mouse are located in a VAXELN runtime system. The VAXELN DECwindows Client provides runtime routines and tools for the development of applications using capabilities of graphics workstations. The VAXELN DECwindows User Environment Components provides Window Manager and terminal emulation support. There is a virtual memory scratch disk. The VM driver for it runs as a job in a VAXELN system. VAXELN Kernel Objects And Operations Processes are the execution threads for VAXELN programs. The main thread of execution (master process) corresponds to the program main routine. Programs can also include special process blocks that are executed by dynamically created subprocesses. The family of a master process and all of its subprocesses is a job in VAXELN terminology. One copy of a program's code is shared by any number of jobs executing that program. Jobs and processes are scheduled on a pre-emptive priority basis. Ports are first-in/first-out queues of messages that are exchanged between processes in a VAXELN application. Port names are provided to ensure the transparency of message-port locations in the local area network. Circuits are bidirectional message paths between two specified ports. Circuits guarantee delivery, blocking and proper sequencing of network messages, and flow control (prevention of a slower receiver process being overwhelmed by a faster sender). Where memory sharing between jobs is a necessity and where the network distribution of the jobs is not an issue, VAXELN provides the AREA object as a means of sharing data among jobs on a single VAXELN node. Events and semaphores are synchronization objects used by multiple processes within a job. Devices are synchronization objects used to synchronize a device driver program with the completion of an interrupt service routine. SOURCE CODE Optional source materials for this software product can be obtained by signing Digital's Software Program Sources License Agreement and then purchasing the desired source option(s). The agreement entitles the user to use the source materials at one customer facility or location which is specified in the agreement. Included in the source kit are the kernel and necessary device drivers for the rtVAX 300 processer. If the rtVAX 300 is to be imbedded into a board with an I/O bus, or used in an application that will utilize DMA operations, customization of the VAXELN kernel to support the full environment may be required. Source components and documentation for kernel customization are included with the VAXELN source kit. Most users do not require source materials, which are used primarily to make modifications to the software product. Source kits provided by Digital do not contain all source files used by Digital to build binary kits. SOFTWARE REQUIREMENTS* For Host Development System VMS Operating System or MicroVMS Operating System * Refer to the System Support Addendum (SSA 28.02.11-x) for availability and required versions of prerequisite/optional software. (R) The DIGITAL Logo is a registered trademark of Digital Equipment Corporation. (TM) VAX, VMS, MicroVAX, VAXstation, VAXserver, VAXcluster, DECwindows, VAXELN, Ethernet and DECnet-VAX are trademarks of Digital Equipment Corporation. HARDWARE REQUIREMENTS Target Processor Support VAX: VAX 6000 Model 200 Series, VAX 6000 Model 300 Series VAX 6000 Model 400 Series VAX 8200, VAX 8250, VAX 8500, VAX 8530, VAX 8550, VAX 8700, VAX 8800, VAX 8810 VAX-11/730, VAX-11/750 VAX RTA MicroVAX: MicroVAX II, MicroVAX 2000, MicroVAX 3100, MicroVAX 3300, MicroVAX 3400, MicroVAX 3500, MicroVAX 3600, MicroVAX 3800, MicroVAX 3900 Board Products: KA620-BA, rtVAX 300 rtVAX Products: rtVAX 1000, rtVAX 3200, rtVAX 3300, rtVAX 3400, rtVAX 3500, rtVAX 3600, rtVAX 3800, rtVAX 6000 Models 200, 300 and 400 Series, rtVAX 8550, rtVAX 8700, rtVAXstation 3100 Models 30 and 38, rtVAX 3305 IVAX Products: IVAX 620, IVAX 630 VAXstation: VAXstation 2000, VAXstation 3100, VAXstation 3150, VAXstation 3200, VAXstation 3500, VAXstation II/GPX VAXserver: VAXserver 3100/3300/3400/3500/3600/3602/3800/3900, VAXserver 6000 Models 210, 220, 310, 320, 410, 420 A VAXELN target system typically requires a memory configuration of 1MB and a ROM based application could have as little as 256K bytes of physical memory on the target system depending on the size of the user's programs and on the toolkit components that are included. The target computer must have a load device for loading the VAXELN system image. The load device is either a Files-11 disk, TU58 cartridge tape, TK70, TK50 or Ethernet adapter (for downline loading). VAXELN systems can also be placed into ROM. OPTIONAL HARDWARE Device drivers or device interface routines are supplied in the Toolkit for the following devices: Supported MicroVAX (Q22) Devices o ADQ32 Analog-to-digital converter o ADV11-C, AXV11-C, and KWV11-C realtime devices o ADV11-D 16 channel, 12 bit A/D converter with DMA o Console terminal o CXA16 Sixteen-line asynchronous multiplexer (DEC423) o CXB16 Sixteen-line asynchronous multiplexer (RS422) o CXY08 eight-line asynchronous multiplexer with modem control (RS232) o DELQA Ethernet-to-Q22 adapter o DEQNA Ethernet-to-Q22 adapter o DESQA ThickWire/ThinWire Ethernet-to-Q22 adapter o DHV11 eight-line asynchronous multiplexer with modem support o DHQ11 supported in DHV11 mode only o DLVJ1 or DLV11-J asynchronous serial controller o DRQ3B or DRQ3B-SA 16 bit parallel I/O with DMA o DRV11-WA and DRV11-J parallel line interface o DZV11 or the DZQ11-SA four-line asynchronous multiplexer o IEQ11 IEEE-488 bus controller o KDA50 Q-BUS Disk Adapter for up to four Digital Storage Architecture (DSA) disks (RA60, RA70, RA81, RA82 or RA90) o KFQSA-SA DSSI controller for RF30 or RF70 o LPV11 line printer controller o MRV11-D ROM option board o MS630 Memory board for the MicroVAX II o MS650 Memory board for the MicroVAX 3500 and MicroVAX 3600 o RQC25 fixed/removable disk subsystem for the RC25 o RQDX1, RQDX2 or RQDX3 disk controller with the following drives as appropriate: RX23, RX33, RX50, RD31, RD32, RD51, RD52, RD53, RD54 o TQK50 for the TK50 Streaming Tapes o TQK70 for the TK70 Streaming Tapes o TU81 Plus, TU81 and TU81E Reel to Reel Tapes o RV20 Write-once Optical Drive Supported UNIBUS Devices o Console terminal o DEUNA or DELUA UNIBUS-to-Ethernet adapter o DMF32 multi-function board (LP-32 line printer, asynchronous-line and modem support.) o IEU11 IEEE-488 bus controller o R80/RL02 combined disk drives (VAX-11/730) o RUC25 fixed/removable disk subsystem for the RC25 o TU58 cartridge tape o TU81, TU81E, TU81-PLUS reel to reel tape o RV20 Write-once Optical Drive o UDA50 Disk Adapter and up to four Digital Storage Architecture (DSA) disks (RA80, RA81, RA82 or RA60) Supported VAXBI Devices o DB88 Additional VAXBI channels o DEBNA Ethernet-to-VAXBI adapter o DEClancontroller 200 (DEBNI) High performance VAXBI Ethernet controller. o DMB32 Asynchronous serial lines, line printer support and modem support o MS820 VAXBI memory option o DRB32-E, -M or -W high speed parallel port interface (DMA) o DWBUA VAXBI -to-UNIBUS adapter o KDB50 VAXBI -to-RA series disk adapter o TU81 Plus, TU81 and TU81E Reel to Reel Tapes o RV20 Write-once Optical Drive Supported Devices For Busless Systems o DHT32 eight line serial port option (MicroVAX 2000) o DSH32 eight asynch serial lines (synch line not supported) (VAXstation 3100) Supported SCSI Devices o A disk class driver is included for the VAXstation 3100 that supports the RZ22, RZ23, RZ55 and RZ56 hard disks, the RZ23 diskette drive and the RRD40 compact disk.
benyukhi@motcid.UUCP (Ed Benyukhis) (07/21/90)
You have also missed the UNIX/RTR (DMERT) that runs on the 3B20D(s)
StG@hummer.iupui.edu (Scott Griepentrog) (07/21/90)
In article <2931@zipeecs.umich.edu> walden@dip.eecs.umich.edu (Eugene Marvin Walden) writes: > > I was wondering if anybody knows of any other commercial real-time operating >systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 7. Kadak > > All of the above except #6 (Alpha) are really not true real-time operating >systems, because there is no provision for handling deadlines. The Alpha op- >erating system is state-of-the-art, but I don't know anything about its avail- >ability. I supose that depends on your definition of real-time. Could you explain a little more about what this deadline handling feature is used for, and why that is part of the definition of a real-time OS? Just curious, StG
baj@hrshcx.csd.harris.com (Barry Johnson) (07/23/90)
In article <2931@zipeecs.umich.edu> walden@dip.eecs.umich.edu (Eugene Marvin Walden) writes: > > I was wondering if anybody knows of any other commercial real-time operating >systems than the ones listed below: > > [ ... list that didn't include my company ... ] > Sigh. Since our two arch-rivals (Concurrent and Encore) have leapt in with their responses, I must as well. CX/UX, CX/SX, and CX/RT are all high-end standards-based real-time operating systems for the Harris Night Hawk super-micro systems, designed for the real-time simulation and radar markets. Night Hawk systems currently available support up to 8 68030's or 4 88100's, in packages ranging from small rack-mounts (19" inch rack, 15" high) to larger free-standing units. All three operating systems include: . POSIX 1003.1 compliance . Virtually all functions of POSIX 1003.4: async I/O, real-time files, message queues, process memory locking, real-time scheduling techniques, binary semaphores, shared memory, synchronized I/O, and support for the built-in clocks & timers. (1003.4 async event notification coming soon!) . SVID compliance, and BCS/OCS compliance for the 88K boxes . Frequency Based Scheduler, with Performance Monitor and Data Recording . Preemtive schedulers, with preemption independent of kernel or user mode. . Priority inheritance for processes blocked by lower-priority processes . Universe switch (currently supports virtually all of SVR3 and BSD 4.3, and you can invent your own universes if you want) . Common Code Generator compiler technology (allows us to provide the _same_ compilers on several different architectures) . High-speed process synchronization services (supporting the 1-to-many, many-to-1, and many-to-many models of client-server sequencing) . Rescheduling control... allowing user programs to disable the program switcher for brief periods of time _without a kernel call_. . Support for spinlocks and processor level control, again without kernel calls. . User-Level interrupt routine support (user supplied code is executed in user-mode _at interrupt level_ very quickly -- around 25 microseconds after the interrupt triggers) . Shared memory regions bound to any specific location in either physical memory or I/O space. (Tie the last five together, and you've got all the support you need to write a user-level multi-threaded device driver -- all done without kernel calls for speed) I'm writing this at home from memory, so I'm sure I've forgotton a key feature or three. All three kernels are fully multi-threaded (we gate access to individual table entries in the kernel, rather than gate access to the kernel itself) for fully symmetric multi-processor systems. The kernel lives in "global" memory (up to 128Mb) equally accessable by all CPUs. CPUs may have "local" memory (up to 16Mb each) that they access without contending for the global memory subsystems. CX/UX is the "base" kernel... CX/SX and CX/RT are modified versions of CX/UX. CX/SX is a multi-level secure system, currently being evaluated by the NCSC for B1 level certification. CX/RT is the "minimal overhead" version of CX/UX: all "non-critical" kernel code not required for "production" real-time use is removed. This includes validation of parameters to kernel calls, validation of buffers on I/O calls, resource accounting, profiling support, etc. We're proud of the Frequency Based Scheduler, intended for the simulations commonly done in the aerospace industry. The concept utilitizes a notion of repeated "frames", generally set to occur at periodic intervals (typically 64 to 2000 Hz.) Programs may be set to execute at any given frame, and will be released by the kernel when the frame rolls around. Key to the implementation is low overhead... we've demonstrated applications at 5000 Hz on a 68030. The Performance Monitor allows the user to see min, max, and average execution times (and the frame numbers the min/max happened at!) for each process on the FBS. Idle time and time used by processes not running on the FBS is also reported. The Data Recording feature is cute: any variable in any process (even variables local to a function) may be "snapshot", either interactively or periodically scheduled on the FBS. Data collected by this method may be stored on disc or tape for later analysis of the simulation. Hope this makes your list! We sure like it. ----------------- Barry Johnson Harris Computer Systems Divison Technical Support Specialist Ft. Lauderdale, FL bajohnson@csd.harris.com (305) 973-5353 ...!uunet!hcx1!baj
srp@modcomp.UUCP (Steve Pietrowicz) (07/23/90)
in article <2931@zipeecs.umich.edu>, walden@dip.eecs.umich.edu (Eugene Marvin Walden) says: > > > I was wondering if anybody knows of any other commercial real-time operating > systems than the ones listed below: This seems to have not gotten out the the net the first time I tried it, so I'll repost: --------------------------- REAL/IX has recently been licensed to Groupe Bull of France. REAL/IX systems have also been recently selected by Jet Propulsion Laboratory for NASA's Deep Space Network (DSN), a facility used to track, control, and receive data from deep space probes. MODCOMP's REAL/IX is a fully preemtive, low-latency, realtime UNIX operating system (System V.3). It conforms to AT&T's System V Interface Definition (SVID) and passes the System V Verification Suite (SVVS). It runs on a 68030 based VME system (with SCSI). Features include: o FULLY Preemptive Kernel (no pre-emption windows) o FAST context switch time (Best Case context switch time: approx. 30 microsec) o Directly Connected Interrupts o Loosely Connected Interrupts o Low Interrupt Latency (Maximum Interrupt latency: approx. 100 microsec) o Event Driven Priority Scheduler o Flexible Task Control o Shared Memory Facilities o Preallocation of Resources o Process lock in Memory o High Performance File System o Asynchronous I/O o Priority Based I/O o Direct I/O o High Resolution Timers o Fast Interprocess Communications o Fast Process Synchronization o Common Event Notification o User Extensible System Services and Interrupt Handlers MODCOMP 1650 W. McNab Road Fort Lauderdale, FL 33340-6099 John Worden Phone:(305) 977-1083 Contact John Worden for more information about it. There was recently an article on Realtime Unix systems in System Integration magazine a few months ago. REAL/IX came out on top against all the listed systems. I'll try and get the issue number for you if you can't find it. Note that REAL/IX isn't a total re-write of System V which other companies claim you have to do to get realtime performance. REAL/IX is System V with realtime extensions, and the kernel is fully preemptive kernel. --------------- SR Pietrowicz UUCP: ...!uunet!modcomp!srp
tdonahue@prost.bbn.com (Tim Donahue) (07/24/90)
In article <4272@navy19.UUCP>, benyukhi@motcid (Ed Benyukhis) writes: > >You have also missed the UNIX/RTR (DMERT) that runs on the 3B20D(s) I was under the impression (from the original IEEE Computer article of 1984 or so) that this system was used to control the #4 ESS and #5 ESS circuit switches. Is it also available commercially? Cheers, Tim
mgu@chorus.fr (Marc Guillemont) (08/03/90)
From article <2931@zipeecs.umich.edu>, by walden@dip.eecs.umich.edu (Eugene Marvin Walden): > > I was wondering if anybody knows of any other commercial real-time operating > systems than the ones listed below: > > 1. VRTX (Ready Systems) > 2. IRMX (Intel) > 3. QNX (Quantum Software) > 4. VxWorks (Wind River Systems) > 5. OS/9, OS/9000 (Microware) > 6. Alpha (Concurrent Computer Corp.) > 7. Kadak Chorus syste`mes has a high performance distributed operating system, CHORUS. Its base is the real-time CHORUS Nucleus; it may be complemented by servers in order to build CHORUS/MiX, a full UNIX operating system. Actual version, v3.2, of both products is described below. CHORUS Nucleus v3.2 =================== The CHORUS Nucleus is the heart of the CHORUS family of real-time distributed operating system products, notably the CHORUS/MiX UNIX operating system. Performance tuned to ensure real-time responsiveness and fast Inter-Process Communication, the Nucleus integrates these essential services: - A real-time executive synchronizes and preemptively schedules priority-based tasks - Modern, optimized Inter-Process Communication (asynchronous IPC and Remote Procedure Calls RPC) mechanisms give efficient, transparent access to resources distributed on a network or bus, - A low-level hardware supervisor dynamically loads interrupt and trap handlers, - An advanced (optional) distributed virtual memory manager optimizes distributed object copying. Main Benefits - Rapid real-time response to external events - Simple, dynamic migration, evolution and reconfiguration of systems and servers - Easier, transparent distributed programming with automatic localization - Fast, efficient local and remote RPC and IPC - Contains very short critical sections for maximum interruptibility - Increased continuity of service via enabling technologies for fault-tolerant servers - Enabling technologies for secure systems Real-time Executive - Light-weight threads (tasks/processes) - Preemptive priority-based scheduler - 256 priority levels, FIFO within levels - Synchronization by events and semaphores - Execution control ("suspend", "resume") - Time-slicing (optional) - Separate address spaces (optional) - Time-outs (optional) - Allocation/deallocation of memory Inter-Process Communication - Fast, distribution-transparent IPC and RPC - Optimized local and distant communication including a coupling with the distributed virtual memory manager - Small untyped messages for fastest processing by network interfaces - Efficient low-overhead internal protocols Distributed Virtual Memory Management - Optional: deconfigurable for real-time use - Demand-paged over network so pages are brought into memory only when needed - Can lock virtual memory pages in memory to prevent swap-out - Separate, protected address spaces - Can share memory between different tasks Hardware Supervisor - Dynamic (de)installation of interrupt and trap handlers - User-level handlers can be installed into system space - Multiple priority-ordered handlers Network Manager - Automatic localization of distributed objects providing transparent remote access to distant objects as if they were local - A high-level network interface independent of specific network protocols - Supports standard (OSI and TCP/IP) or private network protocols - Uses the OSIAM protocol manager Reference microprocessors iAPX186, iAPX386, MC68020, MC68030, MC88000 Reference machines AT/386 compatibles, Sun (SUN 3), Reference standards OSI/TOP (layers 1-4), TCP/IP CHORUS/MiX v3.2 =============== An example of the powerful CHORUS technology, Chorus syste`mes' CHORUS/MiX operating system is a highly modular real-time distributed UNIX system conforming to international standards (X/Open). The CHORUS/MiX system is built from the real-time CHORUS Nucleus, thus eliminating the traditional split between development systems and real-time delivery systems. System integration becomes much easier and development time and effort is reduced because cross-development can be eliminated. The CHORUS/MiX system is highly modular to provide substantially greater system flexibility, simpler maintenance and easier adaptation to changing needs. Building on the real-time distributed CHORUS Nucleus's low-level services, CHORUS/MiX supplies the traditional UNIX services with a set of independent servers: a Process Manager, a File Manager, a Socket Manager and a Device Manager. Chorus syste`mes has developed several techniques to distribute, transparently and simply, UNIX programs as well as files throughout a network or across a system bus. As a result, the standard utilities operate on any file or process on the CHORUS/MiX network simplifying administration, using resources more efficiently and increasing the sharing of information between users and programs. Main Benefits - The system is highly modular, permitting, for example, diskless machines without a file system manager. - New file system implementations or extensions can be made and tested at the user level. After testing they can be installed in system space for higher performance. - UNIX kernel tasks as well as user processes are preemptable and scheduled by the CHORUS Nucleus to maintain real-time response even when UNIX is active. - Supports system calls defined by the base-level X/Open standard. Process Management - Real-time processes scheduled preemptively by task priority. - Multiple threads per process. - Threads scheduled by the CHORUS Nucleus. - UNIX signals are sent (transparently across the network if necessary) to the correct threads and child processes. - Distributed processes (programs), including distributed ps and kill. - Optimized remote execution (exec onto another machine). File Management - Transparent distributed file system. - Automatic interconnection of new file systems without user or administrator intervention. - Symbolic links mask shared file locations. - Uses the CHORUS Nucleus's Virtual Memory External Mapper interface for demand-paging across the network and swapping to disk. Device Management - Compatibility library preserves UNIX semantics for easy porting of existing drivers. Reference machines AT/386 compatibles Reference Standards X/Open (base level), POSIX CHORUS is a registered trademark of Chorus syste`mes. CHORUS/MiX is a trademark of Chorus syste`mes. UNIX is a registered trademark of AT&T. OSIAM is a registered trademark of Marben. -- _ __ _ _ _ ___ Marc Guillemont ' ) ) ' ) ) ) / ) Chorus syste`mes /--' __ / / / / __ . . 6, avenue Gustave Eiffel / / ' / / ( (___/_(_/_ F-78182, St-Quentin-en-Yvelines Cedex Tel: +33 (1) 30 57 00 22 Fax: +33 (1) 30 57 00 66 E-mail: mgu@chorus.fr or mgu%chorus.fr@mcsun.EU.net