Disk to disk copying with overclocked memory
On Thu, 11 Mar 2004 00:40:47 GMT, Mark M
wrote: 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. 1. All copies go through memory using at least a block sized buffer of ram. Buffers at least large enough to hold an entire track will be used, probably larger for more effeciency. Data is always copied from a drive to a memory buffer first. Might be directly, using DMA (the M is memory), but it will be to and from memory. What part of memory is used will vary depending on the program and whether you are running it under windows, but a single bit error in the wrong place in memory can be a major problem. 2. If your memory timing is aggressive enough that errors are likely, then there are a number of things that could go wrong. There could be an error in the data that gets copied. You could also have the wrong disk address stored in ram so the data goes to the wrong place. Could be the wrong instruction so the program crashes. Could be any one of hundreds of possible single bit failures that might go unnoticed. ECC would help here (would catch most possible memory errors). If you want reliability in anything (not just copying disks) then don't push your memory (or other components) to the edge. JT |
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. Overclocking could also cause the occasional double bit error which non-ECC memory cannot detect. This would be bad. As JT indicates, this could cause all sorts of mayhem. If you're lucky, windows could execute a broken instruction or reference a memory address in outer space and then blue screen. If you are unlucky it could blunder on using bad data and do something nasty to your file system (or it could harmlessly stick an umlaut onto the screen somewhere.) Hard to predict. cp "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. |
On Thu, 11 Mar 2004 00:40:47 GMT, Mark M
wrote: 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? Yes, a relatively high risk. 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. Yes, that'll _potentially_ cause errors, corrupt the data. 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. It's involved. Hint: Consider what "DMA" stands for. 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? It has the same effect on all, that "IF" the memory is set incorrectly or defective (or motherboard issue, etc), that if errors occur all of the above scenarios are a risk. 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. It's the same risk, but with more memory used there's even a greater chance of errors, not necessarily all occuring in the data transfer but ALSO the OS, so both the backup AND the OS would potentially be using corrupt data... never boot to the OS if there's any question of memory instability, else be prepared and expecting to reinstall everything unless you can restore or recreate every file written during that interval of operation. |
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. -- Chuck F ) ) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! |
CBFalconer 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. You seem to have confused ECC and parity. ECC means error checking and correcting, which involves more redundancy than simple single bit parity error checking. -- The e-mail address in our reply-to line is reversed in an attempt to minimize spam. Our true address is of the form . |
"CJT" wrote in message ... CBFalconer 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. You seem to have confused ECC and parity. Or you have. **** all ram is parity anymore. ECC means error checking and correcting, which involves more redundancy than simple single bit parity error checking. Which isnt seen much anymore. |
CJT wrote:
CBFalconer 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. You seem to have confused ECC and parity. ECC means error checking and correcting, which involves more redundancy than simple single bit parity error checking. Nothing uses parity checking today - that requires writing individual 9 bit bytes. Expanded to a 64 bit wide word (for the various Pentia etc.) the parity or ECC bits both fit in an extra 8 bits, i.e. a 72 bit wide word. If todays systems have no ECC they have no checking of any form. ECC is actually no harder to handle on wide words. Memory configurations that can use parity can use ECC, the reverse is not true. Exception - some embedded systems with smaller memory paths may use parity. -- Chuck F ) ) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! |
On Thu, 11 Mar 2004 10:20:18 GMT, Mark M
wrote: CBFalconer wrote: Nothing uses parity checking today - that requires writing individual 9 bit bytes. Expanded to a 64 bit wide word (for the various Pentia etc.) the parity or ECC bits both fit in an extra 8 bits, i.e. a 72 bit wide word. If todays systems have no ECC they have no checking of any form. ECC is actually no harder to handle on wide words. Memory configurations that can use parity can use ECC, the reverse is not true. Exception - some embedded systems with smaller memory paths may use parity. Does the motherboard have to support ECC? Or can you always put a stick of ECC memeory where there had been non-ECC memory before? For ECC to work, the motherboard has to support it. If you put ECC in a motherboard that doesn't support ECC, it will usually operate just fine, but with no Error correction. JT |
Mark M wrote:
CBFalconer wrote: Nothing uses parity checking today - that requires writing individual 9 bit bytes. Expanded to a 64 bit wide word (for the various Pentia etc.) the parity or ECC bits both fit in an extra 8 bits, i.e. a 72 bit wide word. If todays systems have no ECC they have no checking of any form. ECC is actually no harder to handle on wide words. Memory configurations that can use parity can use ECC, the reverse is not true. Exception - some embedded systems with smaller memory paths may use parity. Does the motherboard have to support ECC? Or can you always put a stick of ECC memeory where there had been non-ECC memory before? The motherboard has to support it, otherwise at best the additional bits that support ECC will be ignored. I find it highly annoying that Intel etc have decided that "consumers" don't need this and so not implemented it in most of the available chipsets. -- --John Reply to jclarke at ae tee tee global dot net (was jclarke at eye bee em dot net) |
Mark M wrote:
CBFalconer wrote: Nothing uses parity checking today - that requires writing individual 9 bit bytes. Expanded to a 64 bit wide word (for the various Pentia etc.) the parity or ECC bits both fit in an extra 8 bits, i.e. a 72 bit wide word. If todays systems have no ECC they have no checking of any form. ECC is actually no harder to handle on wide words. Memory configurations that can use parity can use ECC, the reverse is not true. Exception - some embedded systems with smaller memory paths may use parity. Does the motherboard have to support ECC? Yes Or can you always put a stick of ECC memeory where there had been non-ECC memory before? No. Even if the MB supports ECC you have to have ALL the memory ECC capable before it will function. Otherwise the system can't tell a massive failure from a non-ECC area. -- Chuck F ) ) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! |
All times are GMT +1. The time now is 08:03 AM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
HardwareBanter.com