A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Disk to disk copying with overclocked memory



 
 
Thread Tools Display Modes
  #21  
Old March 12th 04, 06:56 AM
J. Clarke
external usenet poster
 
Posts: n/a
Default

Arno Wagner wrote:

In comp.sys.ibm.pc.hardware.storage Alexander Grigoriev
wrote:
I've had an MB, which occasionally corrupted bit 0x80000000, but only
during disk I/O! And the corrupted bit position was unrelated to I/O
buffers! Of course, standalone memory test didn't find anything. I've had
to modify the test to make it run under Windows and also run parallel
disk I/O threads. In that mode, the failure was detected in a minute. Had
to dump the MB. Replacing memory and CPU didn't help.


Really nasty. Shows that these things have gotten far to complex...


Dunno about that, I ran into something similar with a genuine original PC.
Customer brought it in reporting a parity error. He put his program disk
in, ran it, sure enough a parity error popped right up. I ran a diagnostic
on it overnight, found nothing, put his program in, parity error popped
right up again. Replaced the RAM. Same thing. Tried his program on
another machine, no problem. Never did find out the cause, just replaced
the planar and that was the end of it. Only thing I can figure is that
something was busted in the processor or the supporting circuitry that was
state dependent--had to go through a certain sequence of states before the
error occurred. Should have hung onto the board and dug into it but at the
time I figured (probably correctly) that I'd never get around to it.

Arno


--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
  #22  
Old March 12th 04, 02:49 PM
SpongeBob
external usenet poster
 
Posts: n/a
Default


"Mark M" wrote in message
...
I use a partition copier which boots off a floppy disk before any
other OS is launched.

If I copy a partition from one hard drive to another, then is there
any risk of data corruption if the BIOS has been changed to
aggressively speed up the memory settings?

For example the BIOS might set the memory to CAS=2 rather than
CAS=3. Or other memory timing intervals might also be set to be
shorter than is normal.

I am thinking that maybe the IDE cable and drive controllers handle
data fairly independently of the memory on the motherboard. So
maybe data just flows up and down the IDE cable and maybe the
motherboard is not involved except for sync pulses.

There are three scenarios I am thinking about:

(1) Copying a partition from one hard drive on one IDE cable to
another hard drive on a different IDE cable.

(2) Copying a partition from one hard drive to another which is on
the same IDE cable.

(3) Copying one partition to another on the same hard drive.

How much effect would "over-set" memory have on these situations?

Do the answers to any of the above three scenarios change if the
copying of large amounts of data files is done from within WinXP?
Personally, I would guess that it is more likely that motherboard
memory comes into play if Windows is involved.


How about something easy...Loosen your memory timings.(CAS3)...perform the
copy...then tighten them back up...Voila! No corruption!


  #23  
Old March 12th 04, 06:38 PM
CBFalconer
external usenet poster
 
Posts: n/a
Default

SpongeBob wrote:
wrote

.... snip ...

There are three scenarios I am thinking about:

(1) Copying a partition from one hard drive on one IDE cable to
another hard drive on a different IDE cable.

(2) Copying a partition from one hard drive to another which is on
the same IDE cable.

(3) Copying one partition to another on the same hard drive.

How much effect would "over-set" memory have on these situations?

Do the answers to any of the above three scenarios change if the
copying of large amounts of data files is done from within WinXP?
Personally, I would guess that it is more likely that motherboard
memory comes into play if Windows is involved.


How about something easy...Loosen your memory timings.(CAS3)...
perform the copy...then tighten them back up...Voila! No corruption!


However the partition you want to copy has already been messed up
by the memory faults, in ways that may not show up for months. If
you have ECC installed and active you might get away with it.
Copying corrupt data does not repair it.

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


  #24  
Old March 12th 04, 08:08 PM
SpongeBob
external usenet poster
 
Posts: n/a
Default


"CBFalconer" wrote in message
...
SpongeBob wrote:
wrote

... snip ...

There are three scenarios I am thinking about:

(1) Copying a partition from one hard drive on one IDE cable to
another hard drive on a different IDE cable.

(2) Copying a partition from one hard drive to another which is on
the same IDE cable.

(3) Copying one partition to another on the same hard drive.

How much effect would "over-set" memory have on these situations?

Do the answers to any of the above three scenarios change if the
copying of large amounts of data files is done from within WinXP?
Personally, I would guess that it is more likely that motherboard
memory comes into play if Windows is involved.


How about something easy...Loosen your memory timings.(CAS3)...
perform the copy...then tighten them back up...Voila! No corruption!


However the partition you want to copy has already been messed up
by the memory faults, in ways that may not show up for months. If
you have ECC installed and active you might get away with it.
Copying corrupt data does not repair it.

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



Well...from what was written...the question was theoretical...data
corruption has not occurred, there has been no evidence of system
instability, and he has not copied anything yet. High quality memory can
often handle tighter timings without ill effect. Test with memtest86 and
Prime95 for a few days to be sure of stability. If not...loosen the timings
and copy away! To answer the question...tighter memory timings may or may
not affect data transfer...It all depends on your memory and your system.


  #25  
Old March 12th 04, 08:54 PM
kony
external usenet poster
 
Posts: n/a
Default

On Fri, 12 Mar 2004 14:08:10 -0500, "SpongeBob"
wrote:


Well...from what was written...the question was theoretical...data
corruption has not occurred, there has been no evidence of system
instability, and he has not copied anything yet. High quality memory can
often handle tighter timings without ill effect. Test with memtest86 and
Prime95 for a few days to be sure of stability. If not...loosen the timings
and copy away! To answer the question...tighter memory timings may or may
not affect data transfer...It all depends on your memory and your system.


There is nothing about data transfer that would inherently make it more
susceptible to memory errors... in theory if the memory were to affect
that then everything done on the system is subject to, likley to encounter
these errors. A system certainly could appear to function stabily for a
while with memory errors occuring, depending on their frequency, but it's
the worst possible situation having unknown problems and data corruption
instead of a more extreme case, an immediate OS crash before the OS even
manages to boot, load.
  #26  
Old March 13th 04, 02:10 PM
cquirke (MVP Win9x)
external usenet poster
 
Posts: n/a
Default

Quick Response to Subject Header:

Diskette activity involves DMA, and RAM timings that may be tolerated
for CPU access (thus pass diags) may fail under DMA, Consider this if
crashes when accessing diskettes are the only problems you have.



-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

  #27  
Old March 13th 04, 05:04 PM
Colin Painter
external usenet poster
 
Posts: n/a
Default

"Folkert Rienstra" wrote in message
...
"CBFalconer" wrote in message




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.



Folkert is correct. I did some research into this and standard non-ECC
memory - the kind found in almost all home PCs - does not do error detection
of any kind. The reasoning is that the error rate is so astoundingly low
that the cost of adding the logic to detect errors cannot be justified.

According to one source I found, actual occurrances of memory errors in home
PCs are usually caused by contamination of the DIMM connectors by the
installer. Translation: finger goo causes most of the errors.

cp


  #28  
Old March 13th 04, 05:33 PM
cquirke (MVP Win9x)
external usenet poster
 
Posts: n/a
Default

On Fri, 12 Mar 2004 19:54:41 GMT, kony wrote:

There is nothing about data transfer that would inherently make it more
susceptible to memory errors...


If the DMA system errors while CPU access does not (think square wave
pulse edges, rise time, local charge pump capacitors etc.) then
MemTest86 et al may pass, while UIDE transfers may fail.

Other possibilities:
- buggy VIA 686B Southbridge problem (eats UIDE data)
- bad or noisy UIDE data cables
- bad cache RAM on the HD itself
- static buildup on ungrounded HD

The last is something that bit me; a couple of 32-bit errors in the
midst of a 500M bulk file copy, when the loose HD was not touching the
chassis. Grounding the HD solved the problem, hence cause presumption



-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -

  #29  
Old March 15th 04, 10:25 PM
Arno Wagner
external usenet poster
 
Posts: n/a
Default

In comp.sys.ibm.pc.hardware.storage Colin Painter wrote:
"Folkert Rienstra" wrote in message
...
"CBFalconer" wrote in message




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.



Folkert is correct. I did some research into this and standard non-ECC
memory - the kind found in almost all home PCs - does not do error detection
of any kind. The reasoning is that the error rate is so astoundingly low
that the cost of adding the logic to detect errors cannot be justified.


Actually it is not the logic. That is very simple and cheap.
It is the additional bits needed, which is one per 8 bits and
makes memory (theoretically) 12.5% more expensive. The market
is not willing to pay that much for improved reliability. Sad
but true. (ECC is more expensive because of the additional bit,
but more so because of the lower volume sold.)

According to one source I found, actual occurrances of memory errors
in home PCs are usually caused by contamination of the DIMM connectors
by the installer. Translation: finger goo causes most of the errors.


Incorrect (read: too high) clock settings are more likely the
main source today. The memory contacts have gotten better and
tin-plating is not so common anymore as it was with DIL-memory
and the first generation of DIMMs.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus


  #30  
Old March 15th 04, 10:32 PM
Arno Wagner
external usenet poster
 
Posts: n/a
Default

In comp.sys.ibm.pc.hardware.storage "cquirke (MVP Win9x)" wrote:
On Fri, 12 Mar 2004 19:54:41 GMT, kony wrote:


There is nothing about data transfer that would inherently make it more
susceptible to memory errors...


If the DMA system errors while CPU access does not (think square wave
pulse edges, rise time, local charge pump capacitors etc.) then
MemTest86 et al may pass, while UIDE transfers may fail.


True. But DMA is usually far less agressive in its timing, so
this is a rather unlikely scenario.

Other possibilities:
- buggy VIA 686B Southbridge problem (eats UIDE data)
- bad or noisy UIDE data cables

That should cause CRC errors.
- bad cache RAM on the HD itself
- static buildup on ungrounded HD

No. The HDD is grounded through the power cable and through the
data cable. Unless the whole mainboard is not grounded properly.

The last is something that bit me; a couple of 32-bit errors in the
midst of a 500M bulk file copy, when the loose HD was not touching the
chassis. Grounding the HD solved the problem, hence cause presumption


Strange. The hdd has two low-resistance paths to the chassis.
These should be enough. Hmmm. O.k., so that may cause problems
in some setups. But it cannot be static buildup in the hdd.
Maybe you where statically charged and touched the HDD? That
yould have induced a spike in some logic-lines...

Arno

-------------------- ----- ---- --- -- - - - -

Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
-------------------- ----- ---- --- -- - - - -


P.S.: Like the sig!

--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
"Safe" memory testing Timothy Lee General 1 March 8th 04 09:04 PM
CAS Timings De-Mystified, and other JEDEC Zins of DDR cRAMming...(Server Problems) Aaron Dinkin General 0 December 30th 03 03:29 AM
CAS Timings De-Mystified, and other JEDEC Zins of DDR cRAMming... Aaron Dinkin General 0 December 30th 03 03:12 AM
Buying Kingston RAM chips... Wald General 7 December 6th 03 05:56 AM
Chaintech 7NIF2 motherboard - memory problems Wuahn General 1 July 26th 03 01:29 PM


All times are GMT +1. The time now is 03:19 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.