Questions about DDR RAM

In alt.comp.hardware.pc-homebuilt John Doe
wrote:

In that imaginary situation where you are selling PCs, you are
asking people to pay for something they don't need.

MY point, is it's something they DO need, and you and others are trying
to convince them they don't; when the extra price is a tiny pittance
compared to the extra security.

Your own point that Windows has improved tremendously points out that
*most* of the remaining problems are likely hardware; with memory
problems being most of those. All *other* devices have ECC and such
built in. Even getting crap off the net has error detection and
correction; having had that since the days of the BBS and long before.

With today's HUGE memories, a fault *will* be undetected for a long long
time. Note: *undetected*; not not-causing-problems.

Sometime do a *systems* check on about a dozen computers; running
something like memtest86+ on each for several days; THEN come back and
say, "memory problems don't exist today" ... IF you want to lie through
your teeth.

The real problem of memory-faults is that:
A. We don't KNOW when they happen.
B. We don't KNOW what program or data they botch.
C. We don't KNOW if they cause a problem.
D. We don't KNOW if the problem they cause is serious.
E. We don't KNOW if the data-errors they introduce will hurt anything.

We DO know that they DO happen!
Even with so-called "perfect" memory chips, there are *always* "soft
errors". Radioactive isotopes, cosmic rays, and neutrinos ensure that.

Why NOT guard against such things, when the cost is now so relatively
cheap? Isn't preventing even ONE computer crash per year worth adding
$20 to the cost of a $600 computer? What about having valuable data
destroyed; or six hours of typing blown away?

Most people would agree such a small price would be *well* worth it to
get their data BACK ... why not safeguard it up front? People pay
several times that amount *gladly* to have anti-virus software in their
systems, for very similar reasons of preventing loss of time, money,
software, and more-important, data.

And why oh WHY try to convince people it's a waste of money????

--
_____
/ ' / â„¢
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / _/ _

In comp.sys.ibm.pc.hardware.chips Frank McCoy wrote in part:
It shouldn't add more than 10% to the price of memory;

No, unless used for yield improvement, std 64/72 ECC must cost
at least 12.5% more for components. Due to lower market
volume, it actually costs 30-50% more

The problem isn't Intel or anybody else with the possible
exception of IBM; but there only slightly.

Why do you doubt their design choice to omit ECC?

The problem is custom and history. They didn't do it in
the past, for fairly good and decent reasons. They don't
do it *now* because they didn't do it in the past. That is
NOT a good reason.

Wrong. From the 8088 thru 486, almost all PCs -- IBM and
clones had parity memory. Macs did not. Only with the
Pentium SIMMs did parity morphed to ECC and begin to drop.

The problem is: WITH ECC built in, probably over half the
cases of "Blue Screen of Death" or computer crashes and
foulups *could* be things of the past!

Reference please! BSoD can have many causes.
I suspect software and software patches mostly.
I keep Linux machines up for ~1 yr w/o ECC.

Even in cases where things like poor capacitors cause
spikes, having ECC memory in the machine would obviate a
large portion of those problems.

No, because spikes often hit the busses in parallel.

The original reasons of the extra logic and extra expense
just ARE NOT that relevant any more. They shouldn't
even SELL non-ECC memory, for the relatively tiny
price-differential versus the HUGE difference in reliability.
It's like selling retread tires as new ones for almost the
same price. Sure they're CHEAPER ... marginally.

Again, you presume you know better than Intel, AMD,
Dell, HP, etc.

The worst part is, people could actually be KILLED by such
mistakes made by a computer that might have been corrected
with ECC ... Yet nobody will trace it back to that; just:
"Sorry, the computer crashed!"

Life critical computing and control machinery does
not run on PCs or with MS software.

"I've ran my computer for years without ECC; and it ran
just FINE!" Only that ignores the freezups, crashes,
blue-screens, and other crap that got attributed to software
instead of memory failures. ;-{

Except I've run several just fine without anything
resembling BSoDs with uptimes around a year.

These days people seem to *expect* such failures, when 99.99%
of the ones caused by bad memory (probably well over half)
could be fixed.

Reference please!

Most people ass-u-me that their memory is good; never EVER
running a memory-test other than the completely useless crap
on boot. Hell, most people, if a computer is crapping out,
just replace the whole thing.

Perhaps this is true for most, but I've run intense software
memory testers like memtest-86+ for days and weeks yet never
seen an inexplicable error.

-- Robert

In article ,
says...
On Sun, 7 Oct 2007 21:54:21 -0500, "Del Cecchi"
wrote:


"kony" wrote in message
.. .
On Fri, 5 Oct 2007 15:17:57 +0000 (UTC), Andrew Smallshaw
wrote:

Yes, it did save money but why did the computer industry en masse decide
that it could safely be dispensed with?

Because they don't particularly care if a customer's
calculations/etc end up wrong if it's not guaranteed for
some critical use. The industry didn't actually abandon it
for critical uses.

In fact, for critical usage some companies have gone far beyond normal
SEC/DED error correction in servers.

If you are referring to ECC schemes and not memory mirroring, I'd be
interested in examples that *don't* simply use n Hamming codewords to turn
n-bit-wide full chip failures into correctable events - which really wasn't
that remarkable, revolutionary or heroic when it was first employed - about 20
years ago...

I think you'll find it's been longer than 20 years. More likely
double that.

I suppose I ought to trim the crossposting...

And what fun would that be?

Beat me to it.

--
Keith

In alt.comp.hardware.pc-homebuilt Robert Redelmeier
wrote:

In comp.sys.ibm.pc.hardware.chips Frank McCoy wrote in part:
It shouldn't add more than 10% to the price of memory;

No, unless used for yield improvement, std 64/72 ECC must cost
at least 12.5% more for components. Due to lower market
volume, it actually costs 30-50% more

I said it *shouldn't* cost more; not that it doesn't.
"yield improvements" or not should count for only a few
percentage-points in the total cost. The primary cost of memory these
days is advertising, shipping, packaging, storage, and promotion, NOT
the amount of silicon used.

The problem isn't Intel or anybody else with the possible
exception of IBM; but there only slightly.

Why do you doubt their design choice to omit ECC?

Because, like everybody else, they're price conscious to the point where
a few cents in millions of units is big bucks to them; and with nobody
pointing out (and very few knowing) the advantages of ECC, why should
they promote it? It's not in their best-interest to do so.

The problem is custom and history. They didn't do it in
the past, for fairly good and decent reasons. They don't
do it *now* because they didn't do it in the past. That is
NOT a good reason.

Wrong. From the 8088 thru 486, almost all PCs -- IBM and
clones had parity memory. Macs did not. Only with the
Pentium SIMMs did parity morphed to ECC and begin to drop.

Wrong again.
Most clones had parity *capability*.
Almost none had actual parity memory *installed*.
I know ... I have over a dozen out in the garage; and about four times
that in obsolete memory sticks for all of them; not one of which is
parity-memory. It got so bad you almost couldn't *buy* parity-memory.

Actually, with good reason:
If you put parity-memory in a computer, that actually made it far *more*
likely to FAIL! Why? Because all the computer could do is yell and
scream, "PARITY ERROR!" and crash!

Often, for that very reason, even computers *with* parity memory had it
disabled in the BIOS. Parity-memory being less than useless; unlike ECC
memory which *corrects* errors.

The problem is: WITH ECC built in, probably over half the
cases of "Blue Screen of Death" or computer crashes and
foulups *could* be things of the past!

Reference please! BSoD can have many causes.
I suspect software and software patches mostly.
I keep Linux machines up for ~1 yr w/o ECC.

Even in cases where things like poor capacitors cause
spikes, having ECC memory in the machine would obviate a
large portion of those problems.

No, because spikes often hit the busses in parallel.

But the errors they *cause* are usually memory-errors.
Memory being *far* more susceptible to such; and with far less margin.

The original reasons of the extra logic and extra expense
just ARE NOT that relevant any more. They shouldn't
even SELL non-ECC memory, for the relatively tiny
price-differential versus the HUGE difference in reliability.
It's like selling retread tires as new ones for almost the
same price. Sure they're CHEAPER ... marginally.

Again, you presume you know better than Intel, AMD,
Dell, HP, etc.

The worst part is, people could actually be KILLED by such
mistakes made by a computer that might have been corrected
with ECC ... Yet nobody will trace it back to that; just:
"Sorry, the computer crashed!"

Life critical computing and control machinery does
not run on PCs or with MS software.

Like hell!

"I've ran my computer for years without ECC; and it ran
just FINE!" Only that ignores the freezups, crashes,
blue-screens, and other crap that got attributed to software
instead of memory failures. ;-{

Except I've run several just fine without anything
resembling BSoDs with uptimes around a year.

Pardon my French; but you sound ALL too much like the guy saying,
"Nobody needs anti-virus software! I've ran for *years* now without
any; and *I* don't have any problems!"

These days people seem to *expect* such failures, when 99.99%
of the ones caused by bad memory (probably well over half)
could be fixed.

Reference please!

My own; from maintaining many computers.
You run memory-tests on those failing computers, and likely over 50% of
the time, if you run it long enough, you'll find a failing memory-stick!

Most people ass-u-me that their memory is good; never EVER
running a memory-test other than the completely useless crap
on boot. Hell, most people, if a computer is crapping out,
just replace the whole thing.

Perhaps this is true for most, but I've run intense software
memory testers like memtest-86+ for days and weeks yet never
seen an inexplicable error.

Well, that just explains why *you personally* haven't had the problems I
mention. Not everybody is lucky enough to get perfect sticks; and of
those who don't, most never even suspect. But then, that's what the
manufacturers *expect*. How many people *do* run memtest86+ on their
computers, even among those failing every few days?

How many even *suspect* that a memory problem might be the root of their
troubles; especially with people like you insisting there are no such
problems?

Like I said, you sound like the guy insisting there's no need for
anti-virus software because *he* has never seen such a problem.

Yeah, right.

--
_____
/ ' / â„¢
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / _/ _

Frank McCoy mccoyf millcomm.com wrote:

In alt.comp.hardware.pc-homebuilt John Doe jdoe
usenetlove.invalid wrote:

In that imaginary situation where you are selling PCs, you are
asking people to pay for something they don't need.

MY point, is it's something they DO need, and you and others are
trying to convince them they don't;

You mean "not trying to convince them that they do". It's your baby.

Your own point that Windows has improved tremendously

Nothing like a big antitrust trial to get Microsoft's attention.

points out that *most* of the remaining problems are likely
hardware; with memory problems being most of those.

I just don't get it. Maybe you could provide some citations?

And why oh WHY try to convince people it's a waste of money????

I guess it depends on what they are doing with a computer. How about
the qualification "for the vast majority of ordinary PC users"? A
comparatively extremely large problem is ordinary users not keeping
important files on removable media.










--
_____
/ ' / ƒ"½
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / _/ _

In alt.comp.hardware.pc-homebuilt daytripper
wrote:

On Mon, 8 Oct 2007 23:06:07 -0400, krw wrote:

In article ,
says...
On Sun, 7 Oct 2007 21:54:21 -0500, "Del Cecchi"
wrote:


"kony" wrote in message
.. .
On Fri, 5 Oct 2007 15:17:57 +0000 (UTC), Andrew Smallshaw
wrote:

Yes, it did save money but why did the computer industry en masse decide
that it could safely be dispensed with?

Because they don't particularly care if a customer's
calculations/etc end up wrong if it's not guaranteed for
some critical use. The industry didn't actually abandon it
for critical uses.

In fact, for critical usage some companies have gone far beyond normal
SEC/DED error correction in servers.

If you are referring to ECC schemes and not memory mirroring, I'd be
interested in examples that *don't* simply use n Hamming codewords to turn
n-bit-wide full chip failures into correctable events - which really wasn't
that remarkable, revolutionary or heroic when it was first employed - about 20
years ago...

I think you'll find it's been longer than 20 years. More likely
double that.

I'll let you defend that statement with a cite :-) I'm sticking with the
timeframe being the very early '80's, when Digital started shipping systems
using x4 drams in volume and needed to survive a full chip failure...

ECC memory was used back in the core days, when "core" meant just that.
I remember ECC memory being available for S-100 bus machines; and it was
*old* technology even then.

You've always had to pay extra for it though.
The usual price/performance ratio is about 50% extra; and that hasn't
changed much over the many years; even though it should have with
today's prices on commodity things like memory set more by distribution
than complexity. That's why it doesn't cost nearly twice as much for
1-gig chips as it does for 500-meg chips these days.

I suppose I ought to trim the crossposting...

And what fun would that be?

Beat me to it.

Bad habit of mine ;-)

/daytripper (meanwhile, I'm gonna go dangle flies in front of steelhead :-)

--
_____
/ ' / â„¢
,-/-, __ __. ____ /_
(_/ / (_(_/|_/ / _/ _

On Mon, 08 Oct 2007 22:34:43 -0500, Frank McCoy wrote:

In alt.comp.hardware.pc-homebuilt daytripper
wrote:

On Mon, 8 Oct 2007 23:06:07 -0400, krw wrote:

In article ,
says...
On Sun, 7 Oct 2007 21:54:21 -0500, "Del Cecchi"
wrote:


"kony" wrote in message
.. .
On Fri, 5 Oct 2007 15:17:57 +0000 (UTC), Andrew Smallshaw
wrote:

Yes, it did save money but why did the computer industry en masse decide
that it could safely be dispensed with?

Because they don't particularly care if a customer's
calculations/etc end up wrong if it's not guaranteed for
some critical use. The industry didn't actually abandon it
for critical uses.

In fact, for critical usage some companies have gone far beyond normal
SEC/DED error correction in servers.

If you are referring to ECC schemes and not memory mirroring, I'd be
interested in examples that *don't* simply use n Hamming codewords to turn
n-bit-wide full chip failures into correctable events - which really wasn't
that remarkable, revolutionary or heroic when it was first employed - about 20
years ago...

I think you'll find it's been longer than 20 years. More likely
double that.

I'll let you defend that statement with a cite :-) I'm sticking with the
timeframe being the very early '80's, when Digital started shipping systems
using x4 drams in volume and needed to survive a full chip failure...

ECC memory was used back in the core days, when "core" meant just that.
I remember ECC memory being available for S-100 bus machines; and it was
*old* technology even then.

You've always had to pay extra for it though.
The usual price/performance ratio is about 50% extra; and that hasn't
changed much over the many years; even though it should have with
today's prices on commodity things like memory set more by distribution
than complexity. That's why it doesn't cost nearly twice as much for
1-gig chips as it does for 500-meg chips these days.

If you're going to play out game, do try to keep up: Keith and I were
discussing (ie: "trying to remember" for us old pharts ;-) when bit-scattering
over multi-ECC-codeword schemes were implemented in memory systems.

Not when ECC first appeared. Sheesh...

/daytripper (usenet has a very shallow memory indeed ;-)

On Mon, 8 Oct 2007 23:06:07 -0400, krw wrote:

In article ,
says...
On Sun, 7 Oct 2007 21:54:21 -0500, "Del Cecchi"
wrote:


"kony" wrote in message
.. .
On Fri, 5 Oct 2007 15:17:57 +0000 (UTC), Andrew Smallshaw
wrote:

Yes, it did save money but why did the computer industry en masse decide
that it could safely be dispensed with?

Because they don't particularly care if a customer's
calculations/etc end up wrong if it's not guaranteed for
some critical use. The industry didn't actually abandon it
for critical uses.

In fact, for critical usage some companies have gone far beyond normal
SEC/DED error correction in servers.

If you are referring to ECC schemes and not memory mirroring, I'd be
interested in examples that *don't* simply use n Hamming codewords to turn
n-bit-wide full chip failures into correctable events - which really wasn't
that remarkable, revolutionary or heroic when it was first employed - about 20
years ago...

I think you'll find it's been longer than 20 years. More likely
double that.

I'll let you defend that statement with a cite :-) I'm sticking with the
timeframe being the very early '80's, when Digital started shipping systems
using x4 drams in volume and needed to survive a full chip failure...

I suppose I ought to trim the crossposting...

And what fun would that be?

Beat me to it.

Bad habit of mine ;-)

/daytripper (meanwhile, I'm gonna go dangle flies in front of steelhead :-)

"Robert Redelmeier" wrote in message
...
In comp.sys.ibm.pc.hardware.chips Frank McCoy
wrote in part:
I said it *shouldn't* cost more; not that it doesn't.
"yield improvements" or not should count for only a few
percentage-points in the total cost.

Probably more if it were aggressively done. I think it quite
possible the ECC on CPU L2 caches is for yield improvement
as much as data reliability. I'm even more convinced the
ECC on hard-disks is for density increases.

The primary cost of memory these days is advertising,
shipping, packaging, storage, and promotion, NOT the amount
of silicon used.

Huh? Check the price of chips against the price of built
DIMMs. Chips are over 2/3rds the cost, leaving very little.

Because, like everybody else, they're price conscious to
the point where a few cents in millions of units is big
bucks to them; and with nobody pointing out (and very few
knowing) the advantages of ECC, why should they promote it?
It's not in their best-interest to do so.

A very negative and limited view of business. If they could
produce, prove and advertise more reliable machines, wouldn't
that be worth quite some premium? People really _hate_ when
machines crash. And for good reason, since they often lose
considerable work. There's a lot of money out there waiting
for any mfr. They know it, and would go for it.

History would show that bad cheap drives out good. I give
you microchannel vrs ISA as an example. In fact the
whole consumer PC market is an example. With small margins,
and no evidence that people walking in walmart or best buy
have any interest in paying a premium for some nebulous reliability
claim why should manufacturers waste perfectly good bits.

Servers are a different story.


Wrong again. Most clones had parity *capability*.
Almost none had actual parity memory *installed*. I know
... I have over a dozen out in the garage; and about four
times that in obsolete memory sticks for all of them; not
one of which is parity-memory. It got so bad you almost
couldn't *buy* parity-memory.

I cannot possibly know your experience, but I've had many
motherboards. All the hundreds of dollars of 40 pin SIMM
memory I bought is 9-chip because the mobos would _NOT_
function with 8 chip.

Actually, with good reason: If you put parity-memory in a
computer, that actually made it far *more* likely to FAIL!
Why? Because all the computer could do is yell and scream,
"PARITY ERROR!" and crash!

This was a design decision made by IBM. They considered
a crash better than corrupted data. I agree.
Actually, how was windows supposed to recover from parity error?
IBM didn't write windows.

But the errors they *cause* are usually memory-errors.
Memory being *far* more susceptible to such; and with far
less margin.

Actually, I see more errors originating from the hard-disk
cabling and memory busses than errors on memory cells.

Life critical computing and control machinery does
not run on PCs or with MS software.

Like hell!

Oh? What examples do you have? I do work with such systems
and haven't seen any beyond the occasional MS-Windows based
terminal. And even that was certified and locked.

Except I've run several just fine without anything
resembling BSoDs with uptimes around a year.

Pardon my French; but you sound ALL too much like the guy
saying, "Nobody needs anti-virus software! I've ran for
*years* now without any; and *I* don't have any problems!"

Well of course absence of proof isn't proof of absence, but
you have not provided any corroboration of your assertion that
memory failures are the main cause of BSoD. All my experience
can add is that my BSoD-equivalents are well below what most
people see. I don't buy premium memory (I test intensively
and extensively) and the number of machines I've run make it
unlikely to be pure luck.

Last time I talked to my buddy that tracks failures, it was software
first, then disks, then electronics.
A little research and a few calculations will tell you how often there
will be a memory error.

How seriously you take it depends on how you feel about errors and
especially undetected errors.

My own; from maintaining many computers. You run
memory-tests on those failing computers, and likely over
50% of the time, if you run it long enough, you'll find a
failing memory-stick!

Interesting. Do you run a PC repair business? What service
have those machines seen? How many tests? I've tested over
50 sticks (mostly shortly after purchase, some after 8+years)
12-170 hrs and only had two failures, both new. Apart from
total failures, I've seen about 10 HDs that would throw the
occasional error. Sometimes they wouldn't with a better PSU.

Well, that just explains why *you personally* haven't had
the problems I mention. Not everybody is lucky enough to
get perfect sticks; and of those who don't, most never even
suspect. But then, that's what the manufacturers *expect*.
How many people *do* run memtest86+ on their computers,
even among those failing every few days?

When I've seen machines fail, it usually has been the HD.
Easy to prove.

Like I said, you sound like the guy insisting there's no
need for anti-virus software because *he* has never seen
such a problem. Yeah, right.

Not quite. The "guilt-by-presumed-association" aside, I agree
there is a problem with worms and trojans. Mostly a usage and
configuration problem and largely solveable with privilege
isolation and other measures in the NIST registry entries.
Conventional Anti-virus software is a very poor second. It can
only react to malware it can recognize and find. Which is
none of the new ones, and few of those designed to fly below
the radar. AV software is a cure, but prevention is better.

-- Robert

"daytripper" wrote in message
...
On Mon, 08 Oct 2007 22:34:43 -0500, Frank McCoy
wrote:

In alt.comp.hardware.pc-homebuilt daytripper
wrote:

On Mon, 8 Oct 2007 23:06:07 -0400, krw wrote:

In article ,
says...
On Sun, 7 Oct 2007 21:54:21 -0500, "Del Cecchi"
wrote:


"kony" wrote in message
.. .
On Fri, 5 Oct 2007 15:17:57 +0000 (UTC), Andrew Smallshaw
wrote:

Yes, it did save money but why did the computer industry en
masse decide
that it could safely be dispensed with?

Because they don't particularly care if a customer's
calculations/etc end up wrong if it's not guaranteed for
some critical use. The industry didn't actually abandon it
for critical uses.

In fact, for critical usage some companies have gone far beyond
normal
SEC/DED error correction in servers.

If you are referring to ECC schemes and not memory mirroring, I'd
be
interested in examples that *don't* simply use n Hamming codewords
to turn
n-bit-wide full chip failures into correctable events - which
really wasn't
that remarkable, revolutionary or heroic when it was first
employed - about 20
years ago...

I think you'll find it's been longer than 20 years. More likely
double that.

I'll let you defend that statement with a cite :-) I'm sticking with
the
timeframe being the very early '80's, when Digital started shipping
systems
using x4 drams in volume and needed to survive a full chip failure...

ECC memory was used back in the core days, when "core" meant just that.
I remember ECC memory being available for S-100 bus machines; and it
was
*old* technology even then.

You've always had to pay extra for it though.
The usual price/performance ratio is about 50% extra; and that hasn't
changed much over the many years; even though it should have with
today's prices on commodity things like memory set more by distribution
than complexity. That's why it doesn't cost nearly twice as much for
1-gig chips as it does for 500-meg chips these days.

If you're going to play out game, do try to keep up: Keith and I were
discussing (ie: "trying to remember" for us old pharts ;-) when
bit-scattering
over multi-ECC-codeword schemes were implemented in memory systems.

Not when ECC first appeared. Sheesh...

/daytripper (usenet has a very shallow memory indeed ;-)

I am trying to remember when "package codes" came along, well after the
schemes to deal with x4 by scattering the bits.

Here is a good survey paper from 1984
http://www.research.ibm.com/journal/rd/282/chen.pdf