Error Correction (WAS: Utility to test IDE cable connections?)

David R wrote:

.... snip ...

The "duff" cable worked. But it was giving errors. XP seemed
to detect them but they did not seem to be critical in the sense
of preventing data being stored.

However if I could not sense the cable was "duff" and the errors
were indeed critical then I would be in trouble. This is what I
want to avoid.

Normally the HD system stores and recovers data using various
error detecting protocols, and will do a retry if the action
fails. This doesn't generally cover the transmission over those
cables, however, but any faults there should be fairly gross and
are not likely to go undetected.

However, the memory in your system, if not protected with ECC, is
another matter. There an error will be totally ignored. Here is
something I wrote about two years ago:

A Tale of Two Machines - by Charles Falconer :-)
or What the Dickens
============================================

Your system is updating or moving a file. This may be the
operation of a database application, disk defragmentation, the
opsystem updating the last accessed date, or almost anything. At
some point in the operation the data is residing in memory. Here
comes a cosmic ray which trashes some bit. The result is written
out to storage as a valid value.

Nothing special happens. One week, month, year later you access
that data, or use the executable file that was fouled, and
possibly something obvious happens. Or not, it may just result in
trashing some further dependant data, and the obvious fault gets
postponed further.

In the interim you have dutifully made backups. By now the
backups you made before that cosmic ray happened are long gone,
overwritten, and probably pretty useless even if you still have
them, because most of the data on them is obsolete.

So you restore everything, including that fouled file or files.
Maybe the fault shows up again, and you start swearing at the
hardware, software, wife, dog, whatever. Maybe it waits around
for another period before showing up. But it is lurking there,
waiting to bite at the worst possible time (Murphy ensures this).

Still no sign of hardware troubles. The memory checks out
perfectly (unless you get a suitable cosmic ray during the
check). Backups still do no good. Neither does cursing.

How many days or weeks have you now lost? Your customer has long
gone elsewhere. How many irate calls to some ignoramus on some
help desk have you placed, and at what cost? You may well resolve
it by a full reinstall, but if the fault is in your own data that
won't help either. If you go and buy a new machine and install
those backed up faulty data files the error follows right along
like a tame puppy dog.

Or, another scenario, the dropped bit changes an accounting
value. The resulting reports are off a few dollars (or more, ever
hear of someone getting a pay check cut for an extra million?).
Your customers curse you for flakey service, and go elsewhere.
Maybe the IRS gets snitty about something that doesn't balance,
and attaches your whole business. Murphy carries on.

Here comes the second machine. Now consider the system with ECC
memory installed, enabled, and functioning. It probably slowed
down by some fraction of one percent. Did you notice? It
probably cost you twenty to a hundred US dollars extra. Did you
really notice?

However, the ECC memory system noticed the cosmic ray effect, and
corrected it immediately. You certainly didn't notice that. But
neither did you notice all the other potential problems that could
appear on the non-ECC machine.

Of course you COULD get along without the ECC and be lucky. You
COULD indulge in unsafe sex with some stranger and be lucky. You
COULD ignore that red light and be lucky. At least the cause and
effect are obvious in the red light case.

My recommendation: ALWAYS insist on ECC memory.

--
Chuck F ) )
Available for consulting/temporary embedded and systems.
http://cbfalconer.home.att.net USE worldnet address!