[comp.realtime] OS/2, real-time, question

tss@beta.lanl.gov (Timothy S Sullivan) (10/23/89)

I realize this is an absurdably premature question, but is anyone doing
anything about implementing a real-time OS/2? Given its single-user,
multitasking orientation it would be a great platform for process control,
data acquisition, and the like.

bnathan@ncratl2.Atlanta.NCR.COM (bnathan) (10/24/89)

In article <34689@beta.lanl.gov> tss@beta.lanl.gov (Timothy S Sullivan) writes:
>
>I realize this is an absurdably premature question, but is anyone doing
>anything about implementing a real-time OS/2? Given its single-user,
>multitasking orientation it would be a great platform for process control,
>data acquisition, and the like.

It depends on your definition of real-time, I suppose, but we've implemented
something that I believe qualifies.  Since the announcements have been in
the trade journals, I think its ok for me to discuss it here.  Kentucky Fried
Chicken has purchased from NCR Corp. a system that includes Point of Sales
terminals (nee cash registers) and a 386sx PC that runs OS/2.  Within that
PC, we've placed quasi real-time software that "samples" data from the 
live transaction data (how many chickens have been sold) and issues cooking
instructions to the CRT screens by the chicken cookers.  The PC also 
maintains data files and performs various services for the POS terminals,
all "background" operations on the PC under OS/2.  The CRT/keyboard on the
PC is an interface for the store manager to obtain reports, etc.  This was
implemented on OS/2 1.0 last winter, and installed in stores  starting this
summer, I think.  In fact, I think its been installed with OS/2 1.1, but
since we did the work with 1.0, we used none of the features of 1.1.  (All
the "I thinks" are due to the fact that once the basic architecture was
in place, the development was transferred to a more applications-oriented 
group, and I've sort of lost touch.)

And yes, OS/2 does make a good platform for real-time stuff.  The 
implementation of threads, queues and ram-semaphores, exitlists, and so
forth provides all the mechanisms one really needs.  I can't say how well
it would work for real-time controls at the milli-second precision range,
but in the relatively slow environment I designed for, it was (dare I say
it?) great.

Bob Nathan  (404)441-8143  NCR, 5555 Oakbrook PKWY, Norcross, GA 30093

philf@xymox.metaphor.com (Phil Fernandez) (10/30/89)

In article <1028@ncratl2.Atlanta.NCR.COM> r.nathan@Atlanta.NCR.COM writes:
>In article <34689@beta.lanl.gov> tss@beta.lanl.gov (Timothy Sullivan) writes:
>>I realize this is an absurdably premature question, but is anyone doing
>>anything about implementing a real-time OS/2? Given its single-user,
>>multitasking orientation it would be a great platform for process control,
>>data acquisition, and the like.
>...
>And yes, OS/2 does make a good platform for real-time stuff.  The 
>implementation of threads, queues and ram-semaphores, exitlists, and so
>forth provides all the mechanisms one really needs.  I can't say how well
>it would work for real-time controls at the milli-second precision range,
>but in the relatively slow environment I designed for, it was (dare I say
>it?) great.

At Metaphor, we have recently released an SNA <-> Ethernet/Token Ring
LAN gateway based on OS/2 running on a PS/2.  On the SNA side, we
support LU6.2 communications on SDLC or TR lines; on the LAN side we
support XNS over Ethernet or TR.  As a communications gateway serving
perhaps 15-20+ workstations on the LAN, this qualifies under some
cdefinitions as a real-time application.

The product definitely works, but this implementation effort taught us
some things about OS/2 in this kind of application:

First, there's little information about system performance, either in
documentation or through developers' tools.  So, it's difficult to
model the performance of system services, such as thread creation, IPC
or inter-tread communication, etc.  Also, it's difficult to understand
"second order" effects, e.g., what's the effect on performance of
creating one more thread.

Second, some key services are slow -- thread creation among them.  So,
in applications that depend on "cheap" threads, OS/2 is perhaps not a
great idea.

These comments apply to OS/2 EE 1.1...soon I'll know if 1.2 offers any
real improvements.

phil

(This opinions are mine only, and do not necessarily reflect the
opinions of Metaphor Computer Systems.)
+-----------------------------+----------------------------------------------+
| Phil Fernandez              |             philf@metaphor.com               |
|                             |     ...!{apple|decwrl}!metaphor!philf        |
| Metaphor Computer Systems   |"Does the body rule the mind, or does the mind|
| Mountain View, CA           | rule the body?  I dunno..." - Morrissey      |
+-----------------------------+----------------------------------------------+

valentin@cbmvax.UUCP (Valentin Pepelea) (10/31/89)

>In article <1028@ncratl2.Atlanta.NCR.COM> r.nathan@Atlanta.NCR.COM writes:
>>And yes, OS/2 does make a good platform for real-time stuff.  The 
>>implementation of threads, queues and ram-semaphores, exitlists, and so
>>forth provides all the mechanisms one really needs.  I can't say how well
>>it would work for real-time controls at the milli-second precision range,
>>but in the relatively slow environment I designed for, it was (dare I say
>>it?) great.

To my knowledge, OS/2 is not a real-time operating system, i.e. it does not
guarantee that an even will be processed within a defined amount of time. Just
like vanilla Unix.

You can add as many features you want to the OS, including your precious ram-
semaphores, but that will not change anything.

[There are real-time implementations of Unix.]

Valentin
-- 
"An operating system without memory is     Name:    Valentin Pepelea
 an operating system without virus."       Phone:   (215) 431-9327
                                           UseNet:  cbmvax!valentin@uunet.uu.net
                              - Kodiak     Claimer: these are only bad opinions

bnathan@scotty.Atlanta.NCR.COM (bnathan) (10/31/89)

In article <864@metaphor.Metaphor.COM> philf@xymox.metaphor.com (Phil Fernandez) writes:
>First, there's little information about system performance, either in
>documentation or through developers' tools. 
AMEN (do it yourself.  Don't ask, I can't give it out.)
>or inter-tread communication, etc.  Also, it's difficult to understand
>"second order" effects, e.g., what's the effect on performance of
>creating one more thread.
DITTO
>Second, some key services are slow -- thread creation among them.  So,
>in applications that depend on "cheap" threads, OS/2 is perhaps not a
>great idea.
I believe threads are cheaper than UNIX processes (though I may be proved
wrong by REAL experts), and for the times when I needed a quick thread,
I just "pre-created" it and made it wait on a ram-semaphore.  Clearing
a ram semaphore gets an existing thread going real quick.

-bob (Standard disclaimer: I said "I", not "WE")
r.nathan@Atlanta.NCR.COM (404)441-8143 5555 Oakbrook #140; Norcross GA 30093

jimb@athertn.Atherton.COM (Jim Burke) (11/15/89)

In article <1229@iraun1.ira.uka.de> grunwald@Tokyo.UUCP (Grunwald Betr. Tichy) writes:
>OS/2 is not designed to serve as an process automation tool, therefore don't
>use it in that field, you can't trust OS/2 in that field.

Yes, but "process automation" is a broad term.  IBM has worked to heavily
promote OS/2 and some associated products in the discrete manufacturing
arena and have convinced some fairly heavy hitters (e.g. Ford Motor).
While discrete manufacturing is not a real-time intensive as continuous
process, it is none the less a form of process automation.  Of course
you have to take the system's architecture into account when designing
your automation application, but then that's always the case isn't it?



-- 
******                Views expressed herin are my own               ******* 
Jim Burke - consultant  408) 734-9822   | I'll stop posting when they pry my 
jimb@Atherton.COM                       | cold, dead fingers from the smoking
{decwrl,sun,hpda,pyramid}!athertn!jimb  | keyboard.