🚀 go-pugleaf

In article <1510@batcomputer.tn.cornell.edu> garry%cadif-oak@cu-arpa.cs.cornell.edu writes:
>In article <3576@utcsri.UUCP>, greg@utcsri.UUCP (Gregory Smith) writes:
>> This is silly. Broken computers don't give wrong answers. They crash,
>> or they log soft errors, or they act flaky. It is almost impossible to
>> imagine a hardware fault that would have no visible effect other than
>> to make the 'value' (whatever it may be) of the output wrong.
>
>Can't help donating my favorite horror story: there's a Vax upstairs that 
>once upon a time a little trouble with some very involved computations. 
>After telling the user in question, for a couple weeks, to fix his program, 
>we decided to investigate. Diagnostics ran fine. After much elaborate head-
>scratching, we happened to ask it to plot out a nice sine curve. The curve
>looked fine too - except for a spike or two. Our jaws dropped. We 
>checked that plotting program five ways from Sunday, and it was OK. We 
>pulled the FP card and the drop-outs vanished.
>

I guess that DEC floating point boards get real strange when they break.
We ran some benchmarks recently on some new hardware and our old 750
The benchmarks on the 750 took twice as long as they had 1 year ago.
We examined everything we could and eventually determined that the
FP card had gone bad. The computer still recognized it as being there, but
all floating point instructions generated faults and I guess the CPU
interpreted the faults as a missing FP board and activated the emulation 
routines. So, no crashes, no wrong answers, just half speed. Real wierd huh?
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb