Sender: |
|
Date: |
Tue, 17 Mar 1998 12:58:03 -0800 |
Reply-To: |
|
Content-type: |
text/plain; charset=US-ASCII |
Subject: |
|
From: |
|
Content-transfer-encoding: |
7BIT |
MIME-Version: |
1.0 |
Organization: |
General Magic |
Comments: |
|
Parts/Attachments: |
|
|
On 16 Mar 98 at 9:21, [log in to unmask] wrote:
> > ECC stands for Error Checking and Correcting.
Apparently this is the official answer expected on one of the
Microsoft Ceritification exams. However, ECC has stood for
"Error-Correcting Code" (describing the underlying technique now
being delivered as a feature) for 20 years or more, and continues to
do so on the literature of most memory and chipset producers.
> > Depending on the chipset
> > and circuitry used on the motherboard, for ECC to be utilized, your
> > memory must be either Parity RAM or ECC RAM. (Both of these types of
> > RAM use 9 bits instead of 8 bits per byte. See below.)
>
> Excuse me if my suppositions are wrong, since I yet have to see
> an ECC memory.
> ECC should use more that one aditional bit every eight. For ECC
> to occur, on a 32 bit wide path, six aditional bits would be needed,
> since 2^6=64, it can point to the bit in error within the 38 bits,
> and include the no error case.
> See that reducing to five, 2^5=32 can't cover all cases.
> (2^p must be greater than n+p+1).
> 32 bits -> 6 parity bits.
> 64 bits -> 7 parity bits. It seems that here ECC is more efficient
> than a parity bit per byte.
This would be why we never saw an ECC feature until after we got to
CPUs with a 64-bit data path to memory, where suddenly the 8
available parity bits are sufficient to implement ECC across either a
DIMM or a matched pair of SIMMs. [Thanks, Javier, for doing the
math!]
David G
|
|
|