Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!swrinde!zaphod.mps.ohio-state.edu!samsung!rex!uflorida!travis!hrshcx!baj
From: baj@hrshcx.csd.harris.com (Barry Johnson)
Newsgroups: comp.realtime
Subject: Re: Real-Time Operating Systems
Summary: "High-End" RT/OS described
Message-ID: <658@hrshcx.csd.harris.com>
Date: 23 Jul 90 12:55:50 GMT
References: <2931@zipeecs.umich.edu>
Reply-To: baj@csd.harris.com (Barry Johnson)
Organization: Harris Computer Systems, Ft. Lauderdale, FL
Lines: 111

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