🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #20803

Re: Parity on Apple memories

#20803
From: Paul Cantrell
Date: Mon, 26 Oct 1987 20:24
53 lines
3272 bytes
Steve Falco stated that he would not like to trust Apple computers
with large sums of money, because of the lack of parity. Then

In article <7118@oliveb.UUCP> gnome@oliveb.UUCP (Gary) writes:
>Parity is pretty useless in the IBM-PC marketplace,  where it exists
>more as a data-sheet compatibility issue than a technical one.
>After all, when the system detects a parity error, it just halts.
>(Wow, how useful -- it doesn't close files, or in the case of UNIX
>on the PC, a SYNC)
>
>So, if you want a system that is super-reliable, design-in ECC and
>software that verifies bus/IO transactions.
>
>There are a bunch of hardware/software safeguards that can be
>designed into medical/financial computers, but each additional
>feature increases the price a little and is not very high on most
>users priorities.
>
>It wouldn't be hard to make a "secure Mac" -- but then, how do you
>guard against bad code?
>
>Gary

Sorry 'Gary', but I have to agree with Steve Falco about this. In my
mind, it is a real shortcoming that the Mac lacks main memory parity.
This was probably a reasonable decision for Apple to make on early
computers like the Apple II which had small amounts of memory, and
was not (often) being used to run nuclear reactors. However, as people
begin to use the Mac for engineering and financial purposes, and as
memories get larger and larger, I believe it is important for the
main memory system to have some checking built in.

Note that I don't think the Mac needs ECC memory as Gary suggested.
I don't want a super-reliable Mac that can keep running with half the
hardware smoked out. What I DO want to see is a Mac that detects that
a memory error has occurred, rather than one that may continue to run,
cranking out possibly erroneous results. At least if the system detects
a parity error and bombs, I know I have a problem to look into.

An example would be an engineer using his user-friendly MacStress program
to design  a bridge. A memory error in the current system might cause
a bug that would crash the Mac, or it might just alter some data in a
way which does NOT cause the Mac to bomb, but DOES cause the bridge to
fall down. People could be killed (or huge sums of money lost) because
Apple saved $50 on a $7,000 Mac II engineering system.

I'm sure readers of comp.risks could tell us of other hardware (and
software) failures which can cause large loss of life or money if
results of computer programs are believed without any cross checking
for reasonableness, however I think Apple is missing the boat by not
trying to detect one of the more common hardware failures.

					PC
Technical Details
Message-ID: <793@alliant.Alliant.COM>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!necntc!linus!alliant!cantrell
References: <15260@clyde.ATT.COM> <7118@oliveb.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!necntc!linus!alliant!cantrell
From: cantrell@alliant.Alliant.COM (Paul Cantrell)
Newsgroups: comp.sys.mac
Subject: Re: Parity on Apple memories
Message-ID: <793@alliant.Alliant.COM>
Date: Mon, 26-Oct-87 15:24:51 EST
Article-I.D.: alliant.793
Posted: Mon Oct 26 15:24:51 1987
Date-Received: Thu, 29-Oct-87 22:02:51 EST
References: <15260@clyde.ATT.COM> <7118@oliveb.UUCP>
Reply-To: cantrell@alliant.UUCP (Paul Cantrell)
Organization: Alliant Computer Systems, Littleton, MA
Lines: 53