|
PureBytes Links
Trading Reference Links
|
Okay, a few people have busted me privately for not being explicit on
behaviors of different types of RAM so here's revision/clarification
of my previous remarks.
DRAM can be categorized in a few different ways.
I/O architecture: Fast Paged Mode (FPM), Extended Data Out (EDO),
Synchronous DRAM (SDRAM), Rambus DRAM (RDRAM), and the latest and
greatest Double Data Rate (DDR). This list is in order of date of
first appearance in the PC market and is roughly in order of speed,
though there can be exceptions. These are all different architectures
for getting bit values into and out of a DRAM block. DRAM is currently
the biggest bottleneck in getting more processing power from a given
CPU and it has been almost since the PC first appeared in 1981. This
is why a 2Ghz processor doesn't really give you twice the performance
of a 1Ghz processor.
Error Correcting Code: ECC/non-ECC. ECC memory has ECC circuits built
into it so that if a memory cell goes bad, the SIMM/DIMM will still
report the correct value for the bad bit. It has extra bits built
into the SIMM/DIMM for a given number of bits to store the ECC data.
ECC was invented a long, long ago by IBM and is also used on hard
drives. All non-ECC RAM has parity checking. For every 8 bits, there
is a 9th parity bit. Every time one of the 8 bits is read, they are
all added up and the sum is compared to the parity bit. If there is a
difference, the BIOS sticks a HALT instruction into the instruction
stream and your mouse cursor stops moving.
Physical packaging: Single Inline Memory Module (SIMM), Dual Inline
Memory Module (DIMM). These are just physical packaging formats.
Internal buffering: I'm not quite sure on this one but here's my
understanding of it. There are 2 formats: Registered and Unbuffered.
One has internal buffer registers and one doesn't. I don't know why
they didn't call it Registered and Unregistered or Buffered and
Unbuffered, but there it is.
In nearly all cases, an application running on a PC has no idea what
kind of RAM it is running on. There are some proprietary BIOS
implementations that allow an application to query and find out some
of the details of the RAM, but it is very rare and there is no reason
why a general purpose application would need to find out what kind of
RAM it is running on. I have never (in 15 years) written an
application that queried or needed to know what type of RAM it was
running on.
Applications run the same on all RAM except for performance; some RAM
is faster. Aside from performance, the only notable different is with
ECC. ECC allows some fault tolerance in the machine. If a cell goes
bad (this is rare, in 15 years I have seen maybe a half dozen
instances of bad RAM), the ECC circuitry allows the machine to keep
running. Non-ECC memory does not. If a machine is ECC, behavior on
detection of a bad cell is system-dependent as far as I know. Some
systems may notify the BIOS of the fault and this will relay the
message to a system monitor application so someone can do something
about it. Some ECC systems will only notify you on reboot. Some
systems will just keep running until enough cells are corrupted so
that the ECC can no longer compensate. Non-ECC systems usually lock
up as soon as they detect a parity error.
Bottom line: it is wrong to think that an application is more stable
on DDR than it is on SDRAM. The application doesn't know and there
is no stability difference between the two. Properly functioning RAM
will function with all applications. Faulty RAM will fail with all
applications.
Kent
|