Robert Bonomi <bon...@mail.r-bonomi.com> wrote:

> One fairly well-known super computer class architecture from the
> mid 1960s ran without *any* error checking in the CPU *or* main
> memory.  Dr. Seymour Cray analyzed things and concluded the
> significant extra component count for just doing 'parity'
> checking, let alone ECC made for a net _reduction_ in overall
> system reliability, *IF* the machine was run under very tightly
> controlled operating conditions -- the big ones being extremely
> stable power and a very limited temperature range.  So, he
> specified the design to tight tolerances, and ran truely 'naked'
> hardward. Scary, but true.  And, it worked.

CDC-6600 and/or 7600, I presume?

The flaw in that reasoning is that, while an unchecked machine may
indeed be faster and/or have a somewhat better MTBF, the symptom
of a failure may well be silently incorrect results.  If reliable
production results are what's valued, as opposed to time between
detected failures while running diagnostics*, a checked or corrected
design wins hands down.

> This was also a machine where, at any given moment, a fair part
> of the data in the CPU was 'in the wires' ("in transit" from one
> part of the CPU to another), and significant parts of the wiring
> harness had to be of _just_the_right_length_ (speed-of-light
> considerations) for the box to work.

Second- (or third?) hand war story from the manufacturing dept:
Occasionally the instructions would call for pin so-and-so to be
connected to pin thus-and-such with, say, a 6" wire -- when the
pins in question were 8" apart!  The source of the story claimed
that the standard practice in such cases was to use the shortest
wire that would reach, and let the QA dept worry about the fallout.

* A diagnostic is a program that runs when the hardware is
  malfunctioning -- R. F. Rosin.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to