Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!stc!inset!dave
From: dave@inset.UUCP (Dave Lukes)
Newsgroups: comp.arch
Subject: Undetectable hardware errors (Was: Speed is the one true performance metric)
Message-ID: <1105@inset.UUCP>
Date: Thu, 20-Nov-86 04:59:23 EST
Article-I.D.: inset.1105
Posted: Thu Nov 20 04:59:23 1986
Date-Received: Fri, 21-Nov-86 21:48:06 EST
References: <340@euroies.UUCP> <1989@videovax.UUCP> <798@spar.SPAR.SLB.COM> <3576@utcsri.UUCP> <13776@amdcad.UUCP>
Reply-To: dave@inset.UUCP (Dave Lukes)
Organization: The Instruction Set Ltd., London, UK.
Lines: 23

Yup, not all hardware errors are catastrophic.

Once, a machine (Burroughs B6700) had a failure in the floating point
output formatting routines (done using clever COBOL-style editing instructions).
All this did was PRINT OUT the wrong answers.

Worse: it was a dual processor, so you got the wrong answer 1/2 the time.

This was extremely nasty, since the program continued using the RIGHT value.
All the calculations were correct, but the answer was wrong!

Most embarrasing: nobody noticed for a while.
All the students kept coming along saying ``My program gets the wrong answer'',
and, of course, who believed them?

On the same subject, unless you have an error correcting RS232 connection,
how do you know that what you see on your screen is correct? (semi :-),

	En{j{_oy,
-- 
		Dave Lukes. (...!inset!dave)

``Fox hunting: the unspeakable in pursuit of the uneatable'' -- Oscar Wilde