Newsgroups: comp.realtime,comp.os.qnx,comp.os.ms-windows.advocacy,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!utnut!nott!cunews!revcan!quantum!danh
From: danh@qnx.com (Dan Hildebrand)
Subject: Re: Real-time systems:  Windows-NT or QNX
Message-ID: <ynz0avr@qnx.com>
Date: Mon, 17 Oct 94 16:44:00 GMT
Organization: QNX Software Systems
References: <FriOct14102309EST1994@eric>
Lines: 250
Xref: glinda.oz.cs.cmu.edu comp.realtime:7193 comp.os.qnx:2249 comp.os.ms-windows.advocacy:40659 comp.robotics:14460

In article <FriOct14102309EST1994@eric>,
Bernie Kirby <bernie@ecr.mu.OZ.AU> wrote:

>Anyway I've narrowed it down to two (or three) operating systems:
>Microsoft Windows, Windows NT, and the QNX operating system from Quantum
>Computer systems.

We're now called "QNX Software Systems".  We used to call ourselves 
"Quantum Software Systems", but there are over 400 companies in north 
america with "Quantum" in their name and company name/product name 
recognition was becoming an issue for us.  (eg: What did WordPerfect Corp 
call themselves before renaming themselves after their product?  :-).

>In essence what we want to do is run a variety of tasks some at very regular
>intervals, so for these determinacy is a key issue, and others
>when certain events take place such as a key-hit. Each of these tasks might
>correspond to a conceptual level in the controller. We will be dealing
>with the control task from very low levels to high levels. At the very
>lowest levels will be control loops such as PID loops for robot joints.
>Force control will be at the next level and trajectory generation at a
>higher level and so on. The highest level would be a graphical user
>interface of some type though its not quite clear what is required at that
>level. The lowest levels (PID loops and force control loops) would be the
>most important parts of the system so they would have to get priority.
>They need to run at rates between 1000 to 2000 Hz so I suppose accurate
>facilities for timing are needed. Should these tasks run inside interrupts
>connected to a clock or should they run as separate tasks?  Is it best
>to have a rate generator board or can be the PC's clock be used?

The QNX "ticksize" utility lets you set the system timer down to 100 
microseconds, but by using the qnx_ticksize() API you can set it to any 
nanosecond setting (the underlying hardware is limited to the precision of 
the 8254 timer, resulting in an 838.095345 nanosecond granularity).  You 
can then attach a function within your process directly to the interrupt 
handler called for this interrupt, and either have that interrupt routine 
do some work, or simply wake up your process on that interval.  On a 486/66 
the OS interrupt latency is 7 microseconds, and the process scheduling 
latency (time from when your interrupt handler wakes up your process to 
when your process is running, if it was the highest priority, ready process 
in the system at that time) is 13 microseconds.  These numbers allow you to 
get some pretty tight timing intervals.

>I understand QNX use a strategy called pre-emptive scheduling where a
>highest priority task runs where as Windows and Windows/NT have a
>different approach called (I think- but dont quite me :-]) threads (I don't
>quite know how they work so if someone could compare the two that would be
>very helpful).

Both threads and processes can be scheduled pre-emptively - the ideas 
aren't exclusive.  The basic idea is that if an event occurs (a hardware 
interrupt or inter-process communication) that a high-priority process was 
waiting for, the high-priority process "pre-empts" whatever process was 
running and resumes execution.

>Is "preemption" a good strategy for this type problem?

Yes, many robotic systems have been successfully implemented with this 
approach.

>I
>guess it must take some time for tasks to be swapped back to the processor
>so that must be a key-factor,

By "swapped", I assume you mean "swapped to disk".  As long as the 
processes that make up your control application are memory resident, the 
context switch time is simply a measure of the processing the kernel must 
do to save the context of the currently running process, load the context 
of the now-ready process, and resume execution.  QNX, on a 486/66, does 
this in 6 microseconds (2 usecs on a Pentium/90).  Does anyone have some 
numbers for Windows NT and OS/2?

>though if I run my servo-loops as interrupt
>service routines that surely would be the overcome any problems  with
>context switching times.

In general, you don't want to do too much work in an interrupt handler.  
The hardware has a limited number of interrupt priorities, and while your 
interrupt handler is running, interrupts of lower priorities will be masked 
and unable to run.  Another problem is that interrupts have a limited range 
of priorities compared to the priorities that processes can run at.  Often, 
the priority at which an interrupt handler should run will be different 
than the process attached to the interrupt.  By having your interrupt 
handler respond to the hardware interrupt in a minimal manner, and then 
waking up your process to do the work, you can have the realtime work be 
done at an OS-defined priority, rather than that of the hardware interrupt 
priority levels.  By measuring the runtime of your interrupt handler (and 
allowing for worst-case cache "warmth"), you have much tighter control over 
the exection and deterministic response of your system with prioritized 
processes.  You can then follow through with a more rigorous analysis of 
your system and it's abilities to meet your realtime deadlines by using 
RMA, etc.

>Are there any disadvantages of the interrupt
>service routine approach. I'd sure be interested to know what people think
>is the most sensible strategy for doing this type of real-time
>programming. Robustness is an important consideration so bearing this in
>mind which scheduling approach is best suited to our problem.

So long as you keep your interrupt handlers short, system response won't 
suffer and you can better control your determinance.  In OS environments 
(MS Windows, for example) where precise, prioritized process scheduling 
isn't available, you may have no choice but to do the work within the 
interrupt handlers, but even here you'll be limited by the interrupt 
latency of the OS.  Does anyone have some numbers for OS/2 and NT?

>One of the most important considerations is ease of writing device
>drivers.  We don't really want to get bogged down in this area.

Can you describe the devices you'll need drivers for?

>Both
>systems claim some level of POSIX compatibility so I guess devices are
>accessed in both by open/read/write etc calls.

I don't recall seeing any products announced for NT that actually use the 
POSIX runtime environment.  Can anyone comment on this?

>How do the systems compare
>in terms of ease of writing device drivers for things like A/D boards
>Digital I/O boards, etc. Are drivers readily available?

We provide a set of A/D and D/A drivers for a number of data acquisition 
cards in source form.  They can be readily adapted to special needs.

>When it comes to the windowing tasks I suspect that windows has the
>performance advantage since that's what it's really designed for.  What we
>need to make sure of here is that the processor doesn't get bogged down
>updating the screen or running the user  interface when the servo control
>tasks must run.

As long as your realtime control processes are running at a higher priority 
than the GUI processes (and/or threads), this shouldn't be a problem.  I've 
heard a rumor that either OS/2 or NT won't let you set your process 
priorities above that of the user interface processes (they want to always 
maintain a snappy user interface, perhaps at the expense of the realtime 
control you might be trying to do).  Does anyone have any confirmation or 
denial for this rumor?

>That would lead to big problems with the controller. Is
>preemption or threads the better suited strategy here.

As mentioned earlier, threads and pre-emption aren't mutually exclusive 
approaches.  The important point is being able to make your realtime 
processing be able to run at a higher priority than the user-interface, 
whether that processing be a thread in a user-interface process, or a 
separate process entirely.  If you can't force this, you might need to 
network a second machine into the system so that your realtime processing 
is divorced from the machine doing the user interface.

>Would windows be better or QNX?

"Better" is a hard question to answer, with so many other variables also 
being part of the issue.  You need to look at the remainder of your 
application's needs to be able to decide this one.

>What are the key things to look at. Does QNX have a
>windowing system or do we need by one from some other seller. Do they
>exist at all? I suppose Windows is the de-facto standard for Graphical user
>interfaces (correct me if I'm wrong) so how close is QNX to windows in
>this area?

QNX provides a number of graphical solutions:

X11R5/Motif - Complete, including support for the high end video cards (ATI 
Mach64, Matrox MGA, S3/964) and the standard cards as well.

QNX Windows - An mid-sized, object oriented windowing system being used at 
a number of process control sites running QNX.

Photon (current in beta test) - A microkernel GUI that scales for small, 
embedded applications, up to desktop use.  Applications can be dragged from 
screen to screen, even across network nodes.

Watcom Graphics libraries - Libraries are included with the Watcom compiler 
under QNX that are similar to those provided with Microsoft C and Borland 
C.

Finally, our Rundos product allows MS Windows in standard mode to run as a 
process under QNX.  You can then have your MS Windows applications do IPC 
with QNX processes, either locally or across the network.

>The intended application for the robot is hazardous and if the software
>failed the potential for disaster is great. I know we have to take
>responsibility for our own bugs but which systems is more reliable
>or robust. Is there any type of certification for computer systems that
>must run in hazardous environments.

There are hardware certifications that manufacturers can meet (NEMA, etc), 
but software certification usually happens at the system level (ie: 
application, plus OS, plus hardware), and not at the software component 
level.  Different industries have their own standards for this sort of 
thing: nuclear, medical, etc.  A good reason for this is that no matter how 
tested the OS might be, if a developer writes a device driver that has low 
level hardware access but isn't written correctly, the OS is unable to 
protect itself from a crash.  An approach we've taken is to provide tools 
for building fault tolerant networks of machines, with distributed task 
sets and multiple LAN links between machines that allow the system to 
survive failures.  A nuclear reactor monitoring system running QNX is using 
this approach.

>Does either windows NT or QNX have
>such certification. Failing that, it would be nice to know which operating
>systems has the best track record. Are there well known examples where
>each is used in a dangerous environment.

Forgive the marketing speak, but QNX is in continuous use in the nuclear 
industry, medical instrumentation, factory automation, process control, 
traffic light control systems, financial transaction processing (credit 
card and point of sale), etc.  Many people use QNX daily but aren't aware 
of it, since it doesn't greet you in the morning when you turn your 
computer on.  :-)

>QNX calls isself a real-time operating system whereas Windows and Windows
>NT seem to be much more general and broader operating systems that provide
>facilities for real time control. Is is better to go for the generality
>wide spread applicability and large software base of Windows or do you
>think that QNX is better suited for the type of work we intend to do?

You don't necessarily have to make an either/or decision here.  With TCP/IP 
and DOS LAN connectivity, it's perfectly reasonable to use the OS of your 
choice for the user interface on one computer and network to another 
computer running an OS more suitable to your realtime needs.

>Of
>course almost everyone uses windows to some extent or another but I want
>to know which system is the best all-round choice for real-time control
>where the controller must also run a graphical user interface.

You really need to look at more criteria than just these two issues to make 
the decision as to which is "best".

>I would
>really like to know the pros and cons of each system and whether there is
>general consensus that one is better than the other. I have an open mind
>but I don't have the experience necessary to make the best decision.  So
>in summary what I'm asking is which operating system is better for the
>work we are going to do.

Just from personal perspective (working with QNX for several years), I know 
of many successful QNX robotic/GUI implementations, but certainly there are 
many successful implementations using other OS's as well.  You really need 
to define a few more selection criteria to narrow your choice of OS.

>Any thoughts what-so-ever would be greatly appreciated.

Hope I didn't ramble on too long.  :-)
-- 
Dan Hildebrand      danh@qnx.com         QNX Software Systems, Ltd.   
phone: (613) 591-0931 x204 (voice)       175 Terence Matthews          
       (613) 591-3579      (fax)         Kanata, Ontario, Canada K2M 1W8
