From owner-freebsd-hardware@FreeBSD.ORG Tue Apr 6 07:50:49 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A1BF106564A; Tue, 6 Apr 2010 07:50:49 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id CF44D8FC13; Tue, 6 Apr 2010 07:50:48 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o367oijP000899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Apr 2010 00:50:45 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o367oih8000898; Tue, 6 Apr 2010 00:50:44 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA10689; Tue, 6 Apr 10 00:44:30 PDT Date: Tue, 06 Apr 2010 00:43:52 -0700 From: perryh@pluto.rain.com To: bonomi@mail.r-bonomi.com Message-Id: <4bbae638.iyl/bH7Z3/uADuhd%perryh@pluto.rain.com> References: <201004052239.o35MdSbD004555@mail.r-bonomi.com> In-Reply-To: <201004052239.o35MdSbD004555@mail.r-bonomi.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Intel D945GSE vs Zotac ION ITX (was: Support for Zotac MB with nVidia ION chipset) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 07:50:49 -0000 Robert Bonomi 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.