From: eb@felix.Sublink.Org (Enrico Badella)
Newsgroups: comp.realtime
Subject: [VERY LONG] Summary of replies on VRTX, Vxworks, pSOS+ and other RTOSes
Keywords: Lynxos, VRTX, Vxworks, pSOS+, Venix, QNX
Date: 20 Nov 92 11:36:26 GMT
Organization: Soft*Star s.r.l, Torino, Italy

As promissed I'm posting all the replies I received to my query
about experience with a selected group of realtime OS.

I hope I didn't miss anyone since in the last couple of weeks
we had an incredible number of hardware failures on all our
machines that handle incomming mail.

Thanks to all those who took time to mail me. 
What has come out is almost a FAQ.

Enjoy


================================================================================
================================================================================
Marc Maathuis                           Tel:    +33 (1) 30 64 82 57 (direct)
Chorus systemes                         Fax:    +33 (1) 30 57 00 66
6, avenue Gustave Eiffel                E-mail: mm@chorus.fr 
F-78182 St. Quentin en Yvelines Cedex

You might want to take a look at CHORUS, a distributed real-time
microkernel that can be combined with the CHORUS/MiX subsystem, which
is modular fully compatible UNIX System V (R3.2 or R4) implementation.
CHORUS runs on i386/i486, 680x0, ands several other processors.

There are several technical reports on CHORUS available via anonymous
FTP from Chorus systemes, France:  opera.chorus.fr [192.33.15.3],
directory pub/chorus-reports. See the file "index" for an overview.

If you are interested in receiving a documentation package on the
company Chorus systemes and its products based on the CHORUS
technology, just send me an email. If you want any commercial
information, you may contact Joel Morali <joel@chorus.fr>. I'll be
happy to answer any technical questions that you may have.

================================================================================
================================================================================
mhuang@bu-ast.bu.edu (Maohai Huang)
Astronomy Department, Boston University, Boston, MA, USA

I can't say I have much expierences on Lynx for I've just started to use
LynxOS2.0 for my work on an i486/33MHz. Maybe what I say here can be
somewhat informational. And I hope that those having experience on
Lynx and other RTOSes can gives comments, comparisons or whatever
you find about the OSes here.

As for the enviroment, Lynx provides several shells including ksh and dlsh
which I think you'll feel familiar if you use SunOS. But the utilities are
far less abundant. I was told the newest versoin of Lynx v2.1 also includes
tcsh.  

My colleague who was hunting around for real-time unix running on PC
for our project of building a submilimeter radiotelescope chose Lnyx
because of the price and that a similar system has been runing in the Bell
Labs (which is a partner of the project) for several years. Our project
doesn't require the system tightly because the whole control-cycle is about
10 ms and the online data pre-process work are not supposed to be heavy. 

I find the system become much slower when a task with high priority is
runing -- more slower than is supposed. And the entire system stops
reacting to other tasks when making tar to tape. I think that making quick
reaction to high prior task's requirements is essential for realtime
systems, which causes some sort peculiarity when you use them. But at least
now I can't tell how other system reacts on the same hardware platform.
Actually I think a 486 is a pretty good platform for many realtime tasks.

================================================================================
================================================================================
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8

You must be careful when reviewing the literature presented by various OS
vendors. Unless you can duplicate the benchmark claims made, a certain
amount of skepticism is required. Always insist on being able to get the
benchmark code to be able to duplicate their published results. If they
won't provide the benchmark source, then you have to wonder why...

You can go with a Texas Microsystems or Industrial Computer passive
backplane ISA chassis. THeire built MUCH better than regular desktop boxes.
You could also go with 486 on VME. The 486/50 or 486/66 outperforms the
680x0 boards, and I've also heard that they are less expensive because of
the high volume gate arrays they can use.

You might also want to try QNX. I've appended some technical information
on QNX.

The paper "An Architectural Overview of QNX", is available by anonymous ftp 
as /pub/qnx-arch.ps at ftp.cse.ucsc.edu (128.114.134.19). The architecture 
of the QNX microkernel is outlined, and its performance compared to the 
SVR4 UNIX system ( a monolithic kernel ). This paper was recently presented 
at the USENIX Microkernel conference held in Seattle, April 1992. In 
addition, here is a recent press release:


             Quantum Software Systems Announces QNX 4.1:

* Fault-Tolerant, Realtime, Distributed-Processing Capabilities Enhanced *

Quantum Software Systems, Ltd., developers of the QNX realtime operating 
system, have released QNX 4.1, a POSIX-compliant OS based on microkernel 
technology. QNX 4.1 started shipping in July, 1992, and features enhanced
disk I/O, multiple redundant network links, and a 10% reduction in 
context-switch time.

QNX 4.1 represents the culmination of over a decade of research and 
experience with an installed base of over 200,000 microkernel-based, 
message-passing operating systems world-wide. As a result, QNX delivers the 
functionality of a modern OS architecture in a robust package proven for 
mission-critical applications.

A TRUE Microkernel Architecture:

The QNX microkernel provides only the essential process scheduling and 
interprocess communication (message passing) facilities from which all 
the other services in the operating system are built. This approach results 
in a 7 Kbyte microkernel with performance characteristics equivalent to a 
realtime executive. Because server processes can be removed or added, QNX
is scalable from small, ROM-based systems up to large, multiprocessor,
distributed systems. Networking services are provided by extending the
message-passing model to be network-transparent, such that communicating
processes need not care whether they reside on the same or different nodes
on the network. The server processes that provide the remainder of the system
are implemented directly on these services, resulting in a fully distributed
operating system.

Distributed Processing:

By virtue of its microkernel, message-passing architecture, QNX can
take a network of computers and present them to applications as a "single 
logical computer," regardless of how many physical computers are joined by 
the network. Applications developed for this "single computer model" will run
without changes even as the number of computers is scaled to suit the scope of
the project.

This scalability is possible because QNX allows applications to be 
initially written as a team of cooperating, communicating processes on a 
single machine. When connected to a QNX network, those processes can then 
be distributed to run throughout the network (without source-code changes), 
while QNX provides network-transparent messaging between those processes. 
Also, the transparency allows any process to use the resources of any other 
computer in the network, regardless of whether those resources are local or 
remote. With this functionality, computers can boot from the network as 
diskless nodes, and then use any resource (disk, cpu, memory, I/O) on the 
network. Mission-critical applications are aided by using the 
network-distributed messaging to implement "hot standby" systems. Multiple 
redundant network links between network nodes provide protection from 
network failures as well.

QNX Networking Technology:

In order to deliver high-performance distributed processing, traditional 
stack-based network protocols are used only when communicating with non-QNX 
systems. For QNX-to-QNX transactions, a lightweight, QNX-specific network 
protocol is used, delivering nearly the full bandwidth of the network to 
communicating processes (980 Kbytes/second from process to process over 
Ethernet). To the "outside world," the QNX LAN appears as a single, 
multiprocessor entity even though it may be coexisting on the same physical 
LAN as other LAN protocols (as is the case with TCP/IP). Conventional 
protocols are used to communicate with non-QNX systems.

For applications that require even higher network throughput and/or 
additional network reliability, the Network manager provides support for 
multiple LAN links per node. Placing additional network links between 
network nodes improves both the reliability and bandwidth of the LAN. 
QNX automatically load-balances the network traffic over the LAN links 
available for any particular network transaction. Nodes that heavily use
the network can be equipped with additional, point-to-point network links
to enhance throughput and move network traffic from the main LAN to
dedicated links.

Embedded, Realtime Systems:

For ROM-based embedded applications, the modularity of the OS allows the 
developer to omit unnecessary system processes. As a result, a diskless, 
deviceless QNX system can be configured to occupy less than 100 Kbytes. 
With its realtime performance, QNX becomes a viable alternative to realtime 
executives, delivering the functionality of a POSIX runtime and development 
environment, AND providing the sheer performance and small size of a realtime 
executive. In a minimal system, only the microkernel, process manager, and 
the system shared library need be present -- all other system processes are 
optional and can be dynamically started and stopped at runtime, or 
statically bound in at boot time for ROM-based applications. With the 
addition of the small QNX networking module, an embedded system can become 
a network-transparent extension of a larger QNX environment for distributed 
applications, booting either from ROM or from the network.


Specifications Overview:

QNX 4.1 Operating System
------------------------
    - Upwards scalable for large, multiprocessor applications
    - Downwards scalable for minimal ROM-based, embedded applications
    - Integrated peer-to-peer distributed processing and networking
    - POSIX-compliant process management
    - POSIX-compliant file and device I/O subsystems
    - Realtime, deterministic response rates
    - Multitasking, multiuser support
    - POSIX 1003.1
    - POSIX 1003.2 Draft Standard utilities and shell
    - POSIX 1003.4 Draft Standard Realtime Extensions
    - Dynamically configurable and extensible at runtime
    - ALL system processes are memory-protected from each other, while the
        microkernel provides interprocess messaging to connect them
    - 386/486 and 286 protected-mode OS
    - Native 80x87 support or 80x87 emulation for reduced-cost embedded
        systems
    - Resource managers and device drivers are fully dynamic, and can be
        started and stopped without rebooting or rebuilding the OS kernel
    - Up to 255 concurrent processes per node

Microkernel
-----------
    - Microkernel occupies less than 7 Kbytes. On a 486, the entire kernel
        and interrupt handlers could reside in the processor cache
    - POSIX 1003.4 Realtime Draft Standard Process Scheduling
        - supports 32 priority levels
        - three scheduling algorithms: FIFO, round robin, and adaptive,
            selectable per process
        - fully preemptive, prioritized context switching
        - servers can have their priority driven by the messages
            they receive
    - Only 12 kernel calls; other services are provided by optional processes
    - Microkernel manages process scheduling and message passing only
    - Microkernel message passing is fully preemptive

Process Manager
---------------
    - POSIX 1003.4 Draft Standard Clocks & Timers
        - Multiple timers per process
        - Timers can be synchronous or asynchronous; one-shot or repetitive
        - Timers specified in nanosecond resolution

    - Additional Features
        - Supports full inheritance of the process environment, even
            across the network for transparent distributed processing; this
            includes open file descriptors, current working directory, and
            environment variables
        - Fully nested interrupts
        - Flexible primitives for shared memory
        - Built-in debug primitives for local and remote debugging from
            anywhere on the network
        - User-configurable system limits and resources
        - Network-wide process-naming capability
        - Interrupt handlers can be dynamically attached and removed

Network Manager
---------------
    - Transparent access to all system resources across the network
    - Modular network drivers
    - Dual-redundant networking for mission-critical applications
    - Redundant network links are automatically used for load balancing
        of network traffic
    - Full inheritance of process environment across the network
    - Applications can send and receive raw network packets for "guest"
        network protocol applications, e.g. TCP/IP
    - Clarkson packet-driver interface
    - Delivers full network bandwidth to the application layer

Device Manager
--------------
    - Fully buffered writes
    - Input buffer per tty can be from 256 bytes to 64 Kbytes for high-speed
        protocol work
    - Input requests can return on timeout or on data-forwarding characters
    - Provides asynchronous I/O primitives
    - Allows even an 8 MHz 286 to handle 38.4 Kbaud without asserting
        flow control

Filesystem Manager
------------------
    - High-performance, extent-based filesystem
    - Disk performance approaches raw platter speed
    - Heuristic read-ahead & write-behind with elevator seeking
    - Robust: all sensitive filesystem info is written through to disk
    - On-disk "signatures" and special key information to allow
        fast data recovery in the event of disk damage
    - Full support for pipes and FIFOs (named pipes), both locally and
        transparently across the network
    - Applications can bypass the filesystem and talk directly
        to device drivers for raw block I/O or "guest" filesystems
    - 48-character filenames
    - User-configurable filesystem limits and resources

DOS Filesystem Manager
----------------------
    - Completely transparent DOS filesystem support
    - DOS media appears as a normal component of the filesystem; any utility
        can be used to manipulate files on the DOS media
    - Supports floppies and all DOS partition types
    - Full access across the network

DOS Emulation - Rundos
----------------------
    - Allows DOS to run as a process under QNX
    - DOS applications can use either the QNX network-distributed filesystem
        or network-distributed DOS filesystems
    - Supports Microsoft Windows 3.1, 3.0 and 2.1
    - Supports Microsoft Windows in real mode and standard (protected)
        mode. This is critical for supporting popular Windows applications
        that do not run in real mode. Large, multi-megabyte Windows
        applications can be easily run.

System Spooler
--------------
    - Suite of control utilities: lp, lpc, lpq, lprm, lpsrvr
    - Multiple queues, filters, and output processes for mapping multiple
        logical printers to multiple physical printers
    - Network transparent

VEDIT Programmer's Editor
-------------------------
    - Multi-window, multi-file, CUA-compliant
    - Mouse support in text mode and within QNX Windows
    - Pulldown menus
    - Integrated help system
    - Columnar blocks
    - 1000-level undo
    - Regular expressions and "short form" pattern codes
    - Small and fast
    - Emulates vi, Brief, WordPerfect, and others
    - Edits text and binary files of any size and line length
    - Powerful macro programming language

Ditto - Remote Diagnostic Utility
---------------------------------
    - Allows remote console viewing and interaction
    - Operates over both network and dial-up links
    - Shipped standard with development system

Development System
------------------
    - Watcom ANSI C
    - Linker, library manager, and disassembler
    - Full-screen, mouse-driven symbolic debugger
    - Full-screen, mouse-driven interactive profiler
    - Symbolic dump file analysis with debugger
    - Standard "make" utility does distributed, parallel compiles
    - Over 500 ANSI, UNIX, POSIX, DOS, and QNX library routines

Graphical User Interface (currently in beta test)
---------------------------------------------------
    - "Smart-object" windowing environment with 3D look and feel
    - "OPEN LOOK" (tm) conforming user interface
    - Full development system
    - Interface editor for interactive application building
    - Designed for demanding realtime applications
    - Much lighter resource requirements than X Windows
    - Supports network-distributed applications

Interrupt and process latency  (times in microseconds)
------------------------------------------------------

                     Interrupt       Context
    Processor        latency*        switch
    ------------     ---------       -------
    33 Mhz 486           6              13
    33 Mhz 386          11              30
    16 Mhz 386SX        32              90
     8 Mhz 286          65             175

  * With nested interrupts, this time represents the worst-case latency
    for the highest priority interrupt. Interrupt priority is user-definable
    and the interrupt latency for lower-priority interrupt sources
    is defined by the user's application-specific interrupt handlers.
    In addition, to guarantee minimal interrupt latency, QNX does not use
    the Intel task-switch instructions.

Hardware Requirements
---------------------
    - Platforms: IBM AT or PS/2 (ISA, EISA, MCA bus)
                 Ampro, Gespac, STD, VME, and other platform support available
    - CPU: 80286, 80386, or 80486 (8086/80186 OEM only)
    - FPU: Optional
    - Memory: 100K (minimal embedded system)
              256K (embedded system with Device and Network Managers)
              512K (OS with filesystem, device I/O, and networking)
              2M  (development system)
    - Disk space: none (target system)
                  5M  (OS & utilities)
                  4M  (development system)*
        * for the combined OS and development system, 9M is required

Technical Support
-----------------
    - Hotline (phone and fax)
    - Online access to Quics for conferencing, private mail, software
        updates and freeware
    - Newsletter
    - Annual international user's conference
    - Training and consulting services available

For more information, reply to this posting or contact:

Quantum Software Systems                      Quantum Software Systems
175 Terrence Matthews Cr.                     Westendstr.19 6000 Frankfurt
Kanata, Ontario K2M 1W8                       am main 1
Canada                                        Germany
voice:  (613) 591-0931 x111 (voice)           voice: 49 69 97546156 x299
fax:    (613) 591-3579      (fax)             fax:   49 69 97546110
usenet: stuartr@qnx.com

================================================================================
================================================================================
Sung Han @ Commonwealth Edison Corp., Chicago, Illinois
sung@ceco.ceco.com, or
uunet!ceco.ceco.com!sung

-------
Forwarded mail follows:
From healy Sun Nov  1 23:07:34 1992
Date: Sun, 1 Nov 92 23:06:44 -0800
From: healy (Mike Healy)
Message-Id: <9211020706.AA13495@cod.nosc.mil>
To: hblim@Trantor.DSO.gov.SG
Cc: healy
Subject: Re::  Comparison of real-time OS's
Status: RO

-------

Here it is. Enjoy :-)

Mike Healy

healy@nosc.mil

----------------------------------------8<--------Cut Here-----------------


>From cwk@irrational.ssc.gov Mon Oct 26 11:55:38 1992
Received: from trout.nosc.mil by cod.nosc.mil (5.65/1.34)
	id AA12034; Mon, 26 Oct 92 11:55:32 -0800
Received: from irrational.ssc.gov by trout.nosc.mil (5.59/1.27)
	id AA09787; Mon, 26 Oct 92 11:55:20 PST
Received: by irrational.ssc.gov (5.57/Ultrix3.0-C)
	id AA09976; Mon, 26 Oct 92 13:54:57 -0600
Date: Mon, 26 Oct 92 13:54:57 -0600
From: cwk@irrational.ssc.gov (Carl Kalbfleisch)
Message-Id: <9210261954.AA09976@irrational.ssc.gov>
To: healy@trout.nosc.mil (Mike Healy)
Subject: Comparison of real-time OS's
Reply-To: cwk@irrational.ssc.gov
Status: RO


Here is some of the stuff I saved related to those discussions.  Some
of the work was done here at the SSC.  The information on it is included as well.

Sincerely,
Carl W. Kalbfleisch

-----------------------


The paper "Overview of Real-Time Kernels at the Superconducting
Super Collider Laboratory" is now available from the Lab Publications
organization.  Copies should be obtained from them.  Please send
a written or verbal request for publication SSCL-397 to:

Rebekah Hafley
Report Co-ordinator
SSC Laboratory
2550 Beckleymeade Avenue, MS-2002
Dallas, Texas 75237

(214) 708-6049
hafley@sscvx1.ssc.gov

The source code for the programs used in the paper are being
distributed by the Energy Science and Technology Software Center.
The KWIC title is Real-Time Benchmark Suite.  They can be contacted at

P.O. Box 1020
Oak Ridge, TN 37831-1020

(615) 576-2606   VOICE
(615) 576-2865   FAX


Thanks for your interest in the paper.

-----------------------

BABYL OPTIONS:
Version: 5
Labels:
Note:   This is the header of an rmail file.
Note:   If you are seeing it in rmail,
Note:    it means the file has no messages in it.

0, unseen,,
*** EOOH ***