Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!newsrelay.netins.net!newsfeed.dacom.co.kr!arclight.uoregon.edu!usenet.eel.ufl.edu!news.mathworks.com!nntp.primenet.com!news1.best.com!nntp1.best.com!flash.noc.best.net!not-for-mail
From: dillon@best.com (Matthew Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.bsdi.misc
Subject: Re: Why one should buy parity memory for reliability?
Date: 25 Sep 1996 10:45:17 -0700
Organization: Best Internet Communications, Inc. (info@best.com)
Lines: 95
Distribution: world
Message-ID: <52br3d$9s8@flash.noc.best.net>
References: <32485B0D.41C6@austin.ibm.com>
NNTP-Posting-Host: flash.noc.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:27995 comp.unix.bsd.bsdi.misc:4984
:In article <32485B0D.41C6@austin.ibm.com>,
:Tushar Patel <tpatel@austin.ibm.com> wrote:
:>Hi,
:>
:>I was going through the FreeBSD hadbook and one of the things suggested
:>in the book is buy "parity memory".
:>
:>I was involve in designing one of the microcontroller for Motorola,
:>one of the things we left out for the future controller was not
:>supporting parity (less pin count). The reasoning was, In the normal
:>condition the error should not happen, if it does then there is
:>somethings seriouly wrong, like having high temprature or more noise
:>in the system. So, the bord designer better design the system correcly.
:>(They had some hard numbers to back the theory and this is just the
:>brif explanation).
:>
:>If the Board supports the parity memory and error occurs then in
:>theory the OS should be notified and the access should be reapeted.
:>
:>Does FreeBSD support such error conditions?
:>
:>What happens in the case of the DMA transfer from the DISK to the
:>memory or from memory to disk, if the memory error occures then
:>processor is not looking at the data bus, so does that mean that the
:>DMA master (SCSI controller) will detect the parity error and
:>retransfer the data?
:>
:>There is a big difference in the price between the parity and non
:>parity memory so I am trying to justify the parity memory purchase.
:>
:>Please make comments.
:>
:>Thanks,
:>Tushar
Parity memory is important for several reasons:
(1) memory densities are increasing and the smaller geometries are
susceptable to radiation. When you throw 512 MBytes onto a
machine, you need to *know* that it works.
(2) board designs generally run their memory subsystems right up to
their rated limit. Not all boards designs are good.
(3) competition in the dram market means memory from a dozen different
manufacturers and, literally, thousands of intermediate SIMM
makers... not all of these are scrupulous or necessarily good
designers.
Without parity memory, it is almost always impossible to tell whether
an error occured due a failure in the hardware or a failure in the
software. This is one reason why most modern high speed microprocessors
incorporate parity in their TLB, primary, AND secondary cache
subsystems, and some incorporate it on the processor control lines on
top of all of that.
Also, most motherboards support hardware ECC... for example, the
pentium pro 200 ASUS motherboards, using the latest Intel 'Natoma'
(I think) chipsets, support hardware ECC with parity memory.
I don't even consider buying non-parity memory any more. It just isn't
an option. I've been burned too many times.
--
I've used motorola microcontrollers... they're really great on the I/O
part, not so great on the cpu or memory interface part. It is *really*
annoying not having an on-demand bus request/grant mechanism, making
it impossible to connect several motorola controllers together on a
single memory bus without spending gobs of money on PALs and buffers.
I've also always been amused by the pidly amount of internal static ram
and e2prom motorola seems to believe people need, it makes using their
parts as single-chip microcontrollers difficult to say the least. On
the one hand, parts like the 68360 and 68xx302 are wonderful for
implementing T1, synchronous, and ethernet on a microcontroller, but
abysmal in the cpu department because they have no internal
instruction or data caches and still use a cmosized 8-15 year old
680lx0 core. On the otherhand, you have something like the MIPS R3071,
with ten times the processing power in a chip with half the pin count, but
no I/O and no built-in dram controller. It just makes me want to
*SCREAM* sometimes(!).
Having parity and the dram controller incorporated *into* the
microcontroller or cpu is the way to go, removing the requirement for
external buffers or muxes and reducing the pin count while at the same
time supporting page mode, burst read, and interleaved dram
subsystems... even wider data busses. Couple that with I/O, a *real*
cpu core, and at *least* an instruction cache, and you have a hot product.
-Matt
--
Matthew Dillon Engineering, BEST Internet Communications, Inc.
<dillon@best.net>
[always include a portion of the original email in any response!]