Newsgroups: sci.space.history
From: henry@spsystems.net (Henry Spencer)
Subject: computers (was Re: Could the shuttle be converted?)
Date: Fri, 30 Jul 1999 03:23:30 GMT

In article <1q2o3.4586$Pt1.1472@wormhole.dimensional.com>,
Eric F. Richards <efricha@flatland.dimensional.com> wrote:
>> Linux offers good networking
>> capability - better than most embedded systems currently have.
>
>...Break the model.  It may be better to have a system that doesn't have
>a concept of a disk drive.  It WILL be better to have a system with
>a slow but entirely predictable networking behavior rather than a fast
>network with unpredictable time of delivery.

It certainly *would* be better to have a system with slow but entirely
predictable networking behavior, if there were any such thing.  There
isn't.  There are only different forms of unpredictability, and different
degrees of willingness to admit their existence.

If you break the model, you have to build your own instead.  That's seldom
honestly cost-effective.

>>   People don't *die* if I don't get a cup of coffee in the morning - usually.
>
>But they *do* if an engine fires one second too long or one second less
>than it should.

Nonsense.  Any system in which lives depend on such split-second timing,
no matter *what* is controlling it, is unacceptably dangerous.  Note how
Apollo lunar-orbit insertion was done in two steps, because slight
overperformance in a single burn might produce too low an orbit.  Note
also how many maneuvers were constrained by the requirement that Earth or
Moon be visible out the window as an attitude check; some of the best and
most carefully developed flight software ever, and still nobody trusted it
when they could possibly avoid that.

>That's right.  But design requirements for Linux (or NT or Solaris or...)
>are very different from the design requirements for a realtime system.
>When you have a realtime action being processed by the CPU, for example,
>it must NOT be interruptible because of the deterministic need.

Determinism does not require absence of interrupts, only adequate bounds
on how much time they take up and how much rescheduling they cause, so
that the realtime action is still known to get *enough* CPU (it does not
have to get 100%) to complete in time.  This problem is greatly eased by
the high speed of modern processors, since big margins simplify almost any
engineering task.

I've done simple real-time control in an interpretive language, on a CPU
slower than the ones in most modern palmtops, time-shared with a dozen
other users.  Worked fine.  You just have to understand the resources and
the margins.

>> 10MB ethernet connector (part number PCM-3660-C)
>
>I don't know the hardware, but I can say that an ethernet
>controller is out--period--for any realtime communication.

Lots of people do realtime communication over Ethernet, or using TCP/IP.
Works just fine, given proper engineering.  If you're about to protest
that Ethernet is nondeterministic, do remember that all its competitors
are too -- just in different ways.  (Tokens get lost, noise disrupts
master/slave protocols, etc.)

>Yes, but the shuttle's computers  -- limited as they are by today's
>standards -- probably use direct, point-to-point communication between
>each computer, have no concept of device storage (but do have data
>storage within their memories), may or may not have virtual addressing
>but won't have page faults, and have the most scrutinized, tested
>code in the world, bar none.

That last is the important part.  Good engineering.

>I'll also bet that they use no interrupts, but do have an event loop.
>(predictability, not speed.)

Nope, sorry, you lose.  Operating system, interrupts, preemptive
multitasking, shared data buses, file systems (on tape, not disk), the
works.  Plus lots of effort and lots of good engineering.

(There is a separate set of backup software, supporting only the minimum
functionality, which is coded much more cautiously and does avoid use of
interrupts and multitasking.  It runs in one of the computers while the
other four run the usual software, and there is a switch-to-backup button
on the pilots' hand controllers.  It has never been used in flight.)
--
The good old days                   |  Henry Spencer   henry@spsystems.net
weren't.                            |      (aka henry@zoo.toronto.edu)