Newsgroups: comp.realtime,comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!news.hal.COM!decwrl!amd!netcomsv!netcomsv!netcom.com!bagpiper
From: bagpiper@netcom.com (Michael Hunter)
Subject: Re: Real-time systems:  Windows-NT or QNX
Message-ID: <bagpiperCxyDBs.F3K@netcom.com>
Followup-To: comp.realtime,comp.robotics
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <jfoxCxs677.K3q@netcom.com> <jfoxCxxs76.D3p@netcom.com>
Date: Thu, 20 Oct 1994 03:50:15 GMT
Lines: 80
Xref: glinda.oz.cs.cmu.edu comp.realtime:7275 comp.robotics:14592

Jeff Fox (jfox@netcom.com) wrote:
: In article <id.B2ZD1.QOA@nmti.com> peter@nmti.com (Peter da Silva) writes
: >In article <tsikesCxtpK5.ICM@netcom.com>,
: >Terry Sikes <tsikes@netcom.com> wrote:

[snip...]

Lets be honest here....some of these numbers are a little outrageous.

: 1. 62 minutes later your WINDOWS based robot reboots due to a system
:    crash and shuts off the laser  beam by accident.

Windows 3.1 use cooperative MT (basically a NPS).  If you turn off VM
response time is order of 100 ms.  I'm assuming reasonable use of the
CPU by all tasks involved which is reasonable if the system was
designed.  We are not talking about a machine that is going to be
running Excel in the foreground.  Still 100 ms is a lot of time.
The coorperative MT makes it hard to design your system IMHO.
On the other hand the estimate of windows crashing every 62 minutes
is probably a bit long :)

: 2. 60 seconds later your WINDOWS NT based robot detects the error and shuts
:    down.

I'm not expert on NT, but I'd assume it is at least as good as 3.1.
People have used it to do tasks with big (order of 100s ms) deadlines.

: 3. 60 miliseconds later your QNX based software detects the error and shuts
:    down.

You could do 10000 context switches during that period of time on a 
DX266 running QNX.  You software would have to be fairly poorly
designed to take this long.  We control hardware devices on the
oterh end of crufty old analog telephone lines with better precision.

: 4. 60 microseconds later your professional realtime Forth software
:     on your Intel based robot detects the error and shuts down.

This would be the time period that a resonable QNX task might be able
to detect a fault of some type (the same statement applies to other
RTOS available, I'm just most familiar with QNX and it appears to
have been an option that the original poster liked.)  My support is
that it takes about 11 us on a 486DX266 to dispatch an interrupt
routine.  That would give you 50 us to detect and act. Probably
reasonable.

: 5. 60 nanoseconds later your Forth hardware robot detects the error
:     and shuts down.

What kind of RAMS/cache ya' got on this system?  Can't get many instructions 
in this period of time!  On a 90 Mhz CPU you only get 5.4 clock
cycles.  On a 66 Mhz CPU you would get *almost* 4 clock cycles.
Now you said "Forth hardware robot".  I'm going to assume you mean
one that is mostly digital w/ some Forth in ROM holding it all together.
I still have a hard time believeing you can do it in 4 cycles unless
it was such a simple error that your digital electronics caught 
it and corrected it in which case Forth vs ??? isn't the question.

: Take your pick.   (and check with the legal dept about insurance.)

: I had mentioned Forth Inc. in my post because although all of the Forth
: projects I have done involved 1-4 programmers they have lots of experience
: with large projects, and large scale applications.  

If an engineer working for me came up with this comarison I would probably
start discounting his advice.  Sorry.  I like and have used Forth and
shameless pushing of Forth as you do above is damaging to Forth.

: The original post suggested the potential for a scene like the one above...
: SO I suggested the kind of code that goes into these critical apps. :-)

: Jeff Fox
: Ultra Technology

While I don't agree with the detail of Mr. Fox's analysis, something
along this line need to be done by the original poster.

		mph
-- 
* Michael Hunter	bagpiper@netcom.com or QUICS: mphunter
