Real Time UNIX Responses (131 lines long)

[Jon A. Tankersley]

Here are the replies that I got to the following query:

Does anyone have any information on any good real-time systems based on
386 and UNIX.  We are looking for some process control systems based on
the 386 that can handle real-time latency down to .25 to .50 seconds.
Please email any replies.
-------------------------------------------------------------------------
>From uunet!ucsd!nosc!celerity!cjk Thu Jun  9 12:07:07 1988

	About a year a go a company called Alcyon was working porting  
their Unix look-alike called Regulus.  Its a SYSV implementation and
definitly real-time.  I only know their phone number and the name of
the VP of software and their parent company's name. The name of the
operating system is Regulus.

Bill Allen, VP software engineering.
Alcyon corp. (now SBE)
San Diego CA.
(619) 587-1155

Chris Kevlahan.
-------------------------------------------------------------------------
>From uunet!ubc-cs!alberta!edm!steve Fri Jun 10 04:26:13 1988

If you write it (and install it) as a device driver, you should have no 
problems at ALL with latencies as slow as .25 seconds. Even as a normal
task (well... niced +20) you're not likely to have too much of a problem.
(I know that XENIX gives you all you need to install a new 'device' I 
assume that microport does as well.. [but don't know for sure])
-------------
 Stephen Samuel 			Disclaimer: You betcha!
  {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve
  BITNET: USERZXCV at UQV-MTS
-------------------------------------------------------------------------
>From uunet!babbage.acc.virginia.edu!mac3n Wed Jun  8 12:09:54 1988

The thing about the PC is it wasn't designed for this - no good clock, etc.
MS-DOS gives you no help.  On the other hand, it doesn't get in your way.
Most of our real-time code makes no use of the operating system.

UN*X wasn't intended for real-time work either.  Having I/O block a process
makes it a real pain, forcing you to use lots of (relatively expensive) tasks,
communicating through sockets or shared memory.  That's why so much code winds
up in the kernel (e.g. TCP/IP).  Mach seems like a better way.

iRMX is not really UN*X-like, but it is a real OS (unlike MS-DOS).
You'll have to get in touch with your local iNtel office for the details.
Things to consider are:

.  We run RMX on a iNtel system 310/286.  I've heard you can get it for a
   PC, but I don't know about a PS/2.  It also costs real $$.

.  The native language for RMX is intel's own language PL/M.  Kind of a
   bastard PL/I or XPL with a little Pascal.

.  There is a C compiler, iC86 (or iC286), derived (I believe) from the
   Mark Williams compiler.  It's serviceable, K&R, able to call RMX system
   routines (keyword ALIEN) with Pascal-style parameter passing.  Not very
   good code generation (PL/M is quite good), but no surprises either.  We
   were able to write all but the bottom-level interrupt handler in C.

.  There are few good development tools.  There is a user's group iRUG that
   collects such things as file compare, a better command interpreter,
   source code management, MS-DOS format disk I/O, etc.  RMX is meant as an
   embedded OS rather than a general-purpose timesharing system.  You can
   configure as much of the OS nucleus as you need, no more..  This can
   make initial system configuration a real mess.

.  There's a hierarchical file system with protection.  Pathnames even use
   "/".  The new shell looks a little more like sh, and can be aliased to
   look more so.  Most system calls (except for the trivial services) are
   asynchronous.  You pass them a "mailbox", where they will drop you a
   "message" when the operation is done.  That means you can do double
   buffering, etc.

.  Atop this layer are other calls that include an implicit wait-for-
   completion.  When you open a file with this library you can specify
   double (or more) buffering.

.  You can also use tasks within a process.  These share memory, but get
   each their own stack.  There's a priority scheduler.  Communication can
   be via mailboxes, semaphores, regions, or just shared memory update.

.  We run RMX86, which doesn't use any kind of memory mapping.  There's
   also RMX286 and RMK386, about which I know little.

Come to think of it, you ought to check out Quantum Software's QNX.
It's more like UN*X, and has real-time goodies.  It's also designed for the
PC.  We looked at it and liked it but couldn't use it for licensing reasons.
Check out their ads in Byte & get a demo disk.

						good luck.
						Alex Colvin
-------------------------------------------------------------------------
>From uunet!hplabs!pyramid!voder!lynx!m5 Tue Jun  7 19:28:41 1988

My company, Lynx Real-Time Systems, is hoping to have our 68K-based
real-time UNIX compatible system running on 386 AT clones by late this
summer.  Our system was written from scratch in-house.  Unlike many
other real-time UNIX systems, *all* tasks running under our system
(LynxOS) have real-time capabilities, plus all tasks can use *all*
system calls (some systems define special "real-time tasks" that can
only do a very limited set of system calls).

LynxOS is patterned after 4.2BSD, but we have almost all System V system
and library calls supported as well.  The system comes with a complete
software development environment and X-Windows.

Give us a call at (408) 370-2233.  Ask for Vik Sohal.

Mike McNally
uucp: ...!voder!lynx!m5
-------------------------------------------------------------------------
>From uunet!babbage.acc.virginia.edu!mac3n Tue Jun  7 12:12:00 1988

How much do you need UN*X?  iNtel has an OS RMX for real-time which is a
lot better at it than UN*X (asynchronous system calls, multiple threads),
but is pretty poor in features.
500 to 250 msec is pretty loose as far as real-time.  You can do that on a PC.
-- 
#include <disclaimer.h>		/* nobody knows the trouble I .... */