Re: Disk to disk copying with overclocked memory

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: J. Clarke (jclarke_at_nospam.invalid)
Date: 03/11/04 

Date: Thu, 11 Mar 2004 08:43:57 -0500

Arno Wagner wrote:

> In comp.sys.ibm.pc.hardware.storage CBFalconer <cbfalconer@yahoo.com>
> wrote:
>> Colin Painter wrote:
>>>
>>> If I can add a bit to JT's reply...
>>>
>>> If you are overclocking your memory you risk getting more errors
>>> than the guys who built the memory planned on. If the memory is
>>> not ECC memory then you may get more single bit errors which will
>>> cause your machine to stop when they occur. ECC memory can
>>> correct single bit errors but non-ECC memory can only detect them
>>> and when that happens windows will blue screen. Most home PCs
>>> have non-ECC memory because it's cheaper.
>
>> Correction here - non ECC memory won't even detect any errors, it
>> will just use the wrong value. Sometimes that MAY cause the OS to
>> crash. Unfortunately the rest of the thread is lost due to
>> top-posting.
>
> Crashes are not your worst enemy. Undetected data corruption is.
>
> I once debugged a fileserver that did flip one bit on average per
> 2GB read or written. This thing had been used in this condition for
> several months by several people on a daily basis. Then one person
> noted that he got a corrupted archive sometimes (was a large file)
> when reading it, and sometimes not. There where likely quite
> a few changed files on disk at that time. If you have files that
> react badly to changed bits, that is a desaster.
>
> The solution was just to set the memory timing more conservatively.
> I made it two steps slower, without noticable impact on performance.
>
> Note on ECC: If you get very little single bit-errors without
> ECC active, ECC will likely solve your problem. If you a lot of
> single-bit errors, or even only very fwe multiple-bit errors, then
> ECC wil not really help and will let errors through. For my scenario
> (single, random bit every 2GB), ECC would have done fine.

The ECC implemented on PCs can typically correct 1-bit errors and detect
2-bit errors.

One machine I worked with came up with a parity error one day. It was about
a week old at the time so I sent it back to the distributer, who, being one
of these little hole in the wall places and not Tech Data or the like,
instead of swapping the machine or the board, instead had one of his
high-school dropout techs "fix" it. The machine came back sans parity
error. Ran fine for a while, then started getting complaints of data
corruption. Tracked it down finally to a bad bit in the memory. Sure
enough the guy had "fixed" it by disabling parity. Should have sued.

This is one of the pernicious notions surrounding the testing of PCs--the
notion that the only possible failure mode is a hang, totally ignoring the
possibility that there will be data corruption that does not cause a hang,
at least not of the machine, although it may cause the tech to be hung by
the users.

But if you're getting regular errors then regardless of the kind of memory
you're using something is broken. Even with ECC if you're getting errors
reported in the log you should find out why and fix the problem rather than
just trusting the ECC--ECC is like RAID--it lets you run a busted machine
without losing data--doesn't mean that the machine isn't busted and doesn't
need fixing.
>
> Arno 

-- 
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)