In a message on 09-05-94, Louis Rizzuto said to Peter Hansen:

PH> The four classes are: time critical, server, regular, and idle.  The
PH> time critical class is similar to the TP stuff you mention, and
PH> would be used for similar purposes.  
  :
LR> Not quite what I asked about (see "high priority" above), but I am
LR> not complaining Peter.  
  :
Sorry, I still can't tell the difference between what you asked ("high
priority...communications") and the time critical priority class of
OS/2.  I got the impression both were simply high priorities that would
be suitable for communications related tasks, among other things. 
Please expand on your "not quite what I asked" comment.


PH> ... "The Design of OS/2" by H.M. Deitel and M.S. Kogan (ISBN
PH> 0-201-54889-5, Addison-Wesley, 1992).
  :
LR> Precisely what I wanted, Peter.  Fantastic.  Does this book go into
LR> sufficient detail to correlate OS/2's software priority scheme to
LR> the 486's, and/or Pentium, hardware priority scheme(s), ...[snip]
  :
It does not appear to do so (from checking the index).  I would guess
that any support the 386+ chips have for this kind of thing is _not_
used by OS/2.  There is at least one case described where the hardware
provides a certain feature but OS/2 implements it in a more efficient
manner (given that the requirements are not an exact match).  I suspect
that would be the case here as well.  Either that, or it is a 486+
feature only, in which case OS/2 will not support it at all, simply to
avoid incompatibility with the 386 chips.  I know as little about Intel
chips as possible while still being able to make money programming for
them. 


LR>   Someone just sent me a msg telling me he saw one Pentium chip that
LR>   did a meltdown - right thru the board - ...
  :
I'm not surprised.  Support PowerPC. :-)


LR> Seems I always get involved in very time critical Real-time apps
LR> projects where responses are pushing the machine to their limits
LR> and where timing constraints are for responses in microsecs - or
LR> worse.
  :
If dealing with microsecs (as in units or tens, not hundreds or
thousands) you cannot consider a general-purpose PC operating system,
period.  You will definitely need a true real-time kernel at the heart
of your system to get that kind of response.

The Design of OS/2 says OS/2 guarantees a maximum interrupt disable
period of 400 microseconds.  Note that this is just the disable time,
not even the interrupt latency period which could be tens of
microseconds longer depending on the maximum length of instructions and
a few other factors.

Thus if you really _really_ need such fast response you cannot use OS/2
in its present form.  I emphasize the _really_ because many people who
think they need such incredible responses do not, in actual fact, need
anything near that (with a properly designed system).  I suspect you are
more than experienced enough to know this but perhaps your client is not
and has misled you.


PH> None of the C++ features cause response/run-time to become
PH> indeterminate, just a little longer.
  :
LR>    "Indeterminate", perish the thought.  :)  You are beginning
LR>    to sound like a mathematician instead of an engineer ...
  :
You insult me! :-)  I mention determinism only because I consider
real-time to be primarily one thing: a defined finite maximum response
time for a given stimulus.  Nothing is said about whether that is ten
microseconds or ten minutes, but the key is that there must be some
*guaranteed* upper limit to the response time.  If the system is
indeterminate, such a finite value cannot be calculated.


LR>    So what you said above is based on theory, or fact?  Based on
LR>    experience with C++ in serious time critical (a few microsecs or
LR>    less) Real-time process control, Peter?
  :
I have not used C++ directly in a *time critical* system (to date) for
two reasons.  The first is that a C++ compiler has not been available
for the majority of the embedded systems on which I've worked.  The
second is that when it comes to *true* time critical systems, such as
the microsecond response you mention, I have never had the luxury of
such incredibly fast hardware that I can afford to use a high-level
language, period.  I have always resorted to assembly for the inner loop
of any fast response system.  

I have, however, written two real-time systems using C++ features (even
with virtual classes) in the inner loop.  As Craig S. said in his
well-crafted response to you, there is nothing in C++ that makes it
unsuitable for real-time, just marginally slower than certain
alternatives.  In the two systems I built with it I didn't need such
fast response that the extra overhead was a problem.  They were
real-time but not so time critical that I couldn't afford to use C++.


LR> What is the alternative if the operating system being used -
LR> without source - doesn't quite deliver the goods?
  :
1. Build your own.  2. Wait.  3. Change your requirements.  :-)

I've already done 1. under DOS and I am actively doing 3. from time to
time.  During all this, I am anxiously awaiting the "Workplace OS"
release of OS/2 (initially for the PowerPC chip) since I am convinced
that will improve the real-time performance of OS/2 beyond the level I
need in the bulk of my applications.  The change from a monolithic OS to
a microkernel-based architecture will be very significant to people like
us who are interested in OS/2 and real-time work.


LR> Well all communications is considered "Real-time" - theoretically,
LR> right?   :)
  :
Not really, IMHO.  There is no connection between the two concepts. 
Communications refers simply to the transfer of information from one
location to another.  This can occur in real-time or not.  It can even
occur in a completely indeterminate sense in which case it is not a
reliable form of communications, although it may still be practical.  
Ethernet is a good example of this.

Ethernet (which I said was not real-time and which comment probably
triggered your statement) is indeterminate since it is possible for
packets to collide for indefinite periods of time without getting
through.  This makes it unsuitable for true real-time applications,
including many industrial ones.  For this reason industrial buses are
usually designed around Token Bus or Token Ring instead of their
brother, CSMA/CD (Ethernet).  Ethernet is great for non-critical
applications for other reasons.


LR> relative to OS/2 and "Real-Time" under it.  Lack of "official
LR> mention" means to me I in a boat that may leak and I got nothing
LR> to repair it with.  
  :
Well, to temper what I said about IBM not officially knowing much about
real-time stuff (or at least, not _publicly_), there are unofficial
reports from many different folks who have used OS/2 for real-time
applications.  Steve Mastrianni, whom I mentioned, replied to my mail
once and stated "I've developed over 30 real-time systems under OS/2,
patient monitors for the ICU, ...opening the bomb bay doors on the F-22,
... injection molding machine controls...."  I consider this proof that
it is possible (at some level of response) to do real-time under OS/2,
but it (a) won't be easy learning how, and (b) won't achieve the same
performance as a dedicated system or custom RT kernel.  Even Steve
couldn't directly answer my query as to whether or not OS/2 could
support my need for closed-loop control operating at around 2000 inner
loop iterations per second with low jitter (250 microsecs tops).


LR>   Big warning bells are now going off in my brain for this project
LR>   thanks to you.  You are affirming my fears.
  :
At the very least your client is out to lunch in wanting to run VxWorks
"on top of" OS/2 (or under it, or beside it...).  If Craig's description
of the product is correct, and I'm sure it is, VxWorks is as much an
operating system as OS/2 and you simply cannot run the two of them
simultaneously.  I have a little real-time kernel for DOS that manages
to run under OS/2's DOS emulation without crashing (a tribute to either
my or IBM's programming :-), but it sure as TI invented the transistor
doesn't have real-time performance that way!  I lost an order of
magnitude in performance trying this out on a lark.


LR> I am not sure how you concluded it is not a OS/2 related issue?
  :
Sorry, I forgot that the client thought VxWorks and OS/2 had some
relation.  They almost certainly don't, but as you thought they did at
the time, you were certainly justified in posting here.  Make sure you
read Craig S.'s message and you can form your own opinion.


PH> ***  Engenuity Corporation  ***  Guelph, Ontario, Canada
  :
LR> Where is Guelph in Canada?  How big is it?  Have you got a lot of
LR> software requirements for consultants up there - for OS/2?
  :
One hour due west of Toronto.  90,000 people.  University town.  Right
next door to Cambridge, Kitchener, and Waterloo.  These cities call
themselves Canada's Technology Triangle and together have something like
500,000 pop, strongly industrial.  OS/2 jobs are whenever I can convince
the customer, and when it's appropriate.  This means none to date. :-(  

I am waiting anxiously for the next release of OS/2 to run in the 4MB
machines in a test lab with which I work closely.  Roughly around the
time it is released, I will have obtained some initial results related
to porting my test applications to OS/2.  If the results are favourable,
this lab will be my first big (4 machines initial, 7 eventual) OS/2
installation for real-time purposes.


Editorial note:  People interested *only* in OS/2 programming please
                 stop reading here.  The following are simply responses
                 to other questions Louis asked.   Thanks.  :-)


LR> ... FidoNet Embedded echo ... in my few casual forrays on that echo
LR> I did meet a few outstanding guys who seem to make a living out of
LR> specializing in Real-Time Embedded Systems - unlike me.  Beats me
LR> how they do THAT.
  :
I won't claim to be out standing in my field (although my ancestors were
farmers :-) but *I* make a living (almost) specializing in real-time
(sometimes embedded) systems.  Well, okay, maybe I don't actually
_specialize_.  Maybe I just think about how much more fun it would be
doing real-time work instead of trodding out another boring data
acquisition routine... :-)


LR> Would you be interested in hearing about software engineering jobs
LR> here in the USA?
  :
Always interested in any such info, provided they are not permanent
positions.  We'd better take that up in the F-Embedded conference,
however, or maybe in F-Consulting (where I know you also visit).


PH> * MR/2 * ***  Learn Esperanto, the  international language.
  :                     ^^^^^^^^^
LR> Is there a compiler for it?  :)
  :
No need, it's directly machine readable!  (Well, almost.  :-)  It's
certainly several orders of magnitude more logical and consistent that
English.  *That* discussion should probably go in the F-Esperanto
conference, which may be kaput, or in soc.culture.esperanto which is a
hotbed of Esperanto activity.)

Cheers,
Peter Hansen  ***  Engenuity Corporation  ***  Guelph, Ontario, Canada
Internet: peter.hansen{at}canrem.com    RelayNet:->CRS    FIDO:(1:229/15)
___
 * MR/2 * ***  Learn Esperanto, the international language.  ***

--- QScan v1.12b / 01-0348