Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!vsi1!zorch!ardent!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: The Killer Micro From Hell [actually, reliability]
Keywords: Tandem Cyclone
Message-ID: <34469@mips.mips.COM>
Date: 15 Jan 90 04:35:21 GMT
References: <34030@mips.mips.COM> <4322@nttmhs.ntt.JP> <39807@ames.arc.nasa.gov> <3101@umn-d-ub.D.UMN.EDU> <28674@amdcad.AMD.COM> <7566@pt.cs.cmu.edu>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 45

In article <7566@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:

>Yes. A case in point is the new Cyclone processor from Tandem. I'm
>not knocking it: I'm sure that it was built by sharp people, and will
>be sold successfully. It has the important property that it's bit-
>compatible with Tandem's previous stack machines.
....
>Is it reliable? Well, yes, it's a Tandem product. It has parity and
>temperature compensation and a diagnostic processor and spare cache
>RAMs. But a Killer Micro with the same throughput could be made more
>reliable, at a lower price, simply from its reduced chip count.

This comparison is somewhat orthogonal to the previous line of discussion,
in that I'd expect the tradeoffs for Cyclones are probably different
from either K.M.'s or supercomputers.  Also, Tandem is obviously aware
of K.M.s and incorporating them into its product line.

However, this might start off a new line of discussion.  There has been plenty
of discussion of the differences between micros and {mainframes, supers}
in areas like I/O.  How about one in the area of reliability, with issues like:
	a) What are CPU differences between micros and mainframes in this area?
	Are there reliability features of current big machine CPUs that
	are impossible to duplicate in micros? hard to duplicate? easy, but,
	too expensive? Are there features of micros that make them easier to
	make reliable systems from?
	b) Are any of these reliability features from mainframes not so
	necessary when entire CPUs are on single chips?
	c) Beyond the CPUs, what are the issues that might be different
	at the system level?
	d) ECC, parity, nothing: where are the boundaries on tradeoffs?
		(example: R3000s require/support parity on caches;
		from customer demand, IDT's 3001 can omit parity to lessen
		costs, because many embedded customers don't want it;
		of course, this would give other kinds of embedded customers
		(avionics, switches for example) nightmares.
		How big does a write-back cache get before you really want ECC?
		How about parity and ECC on busses?
		How about parity on ALU operations?
Needless to say, hard data on error rates, and environmetns in which
errors are OK, not-OK, would be good....
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086