How long should XP NTFS format take?

[Eyeball Kid]

I usually format my 80g Seagate Barracuda using the Seagate tools, however I recently formatted with the native XP NTFS long format. It takes between 40-50 minutes - is this about right? I'm formatting a 40g Maxtor at the moment and it's only taken about 15 minutes. My 80g is on a 3200+, the 40g is on a Celery 1.8 BTW.

[Ice Czar]

well there are a couple of variables in the platforms so I cant really address that
I would point out that the difference between a long format and a quick format is that the long format runs chkdsk, and what it finds could account for the difference in time
(see defect remapping (http://www.pcguide.com/ref/hdd/perf/qual/featuresRemap-c.html))
then either option simply writes the metadata (http://www.pcguide.com/ref/hdd/file/ntfs/archFiles-c.html) (Master File Tables (http://www.ntfs.com/ntfs-mft.htm) ect in a basic disk) and leaves the rest of the disk alone

another possible cause of "long" format time is a bad cable, since IDE employs CRC it hides errors and simply retransmits the data again

[Eyeball Kid]

Is there any utilty for checking cable errors? The drive seems to perform well though, when I run Sandra it gives me ~33k, where a similar 80g NTFS IBM Deskstar gets 29k.

[Ice Czar]

DMA Mode for ATA/ATAPI Devices in Windows XP (http://www.microsoft.com/whdc/device/storage/IDE-DMA.mspx)

All CRC and timeout errors are logged in the system event log. These types of errors could be caused by improper mounting or improper cabling

however that doesnt actually seem to be the case
(from Corruption 101 (http://hardforum.com/showthread.php?t=761272)

----------------------------------------------------------------------------------------------------------------------------
Cables

there is definately a reason why SATA is being adopted, ATA\IDE\EIDE\ATAPI (http://www.ata-atapi.com/hist.htm) is an unterminated standard and as speeds increase that causes more and more problems, especially if cheap cables are employed, complex device configurations, hotswap\removable drivebay bridgecards and poor cable routing

a few (:p) links and excerpts:
Standard (40-Conductor) IDE/ATA Cables (http://www.pcguide.com/ref/hdd/if/ide/confCable-c.html)

In many ways, the cable is the weak link in the IDE/ATA interface. It was originally designed for very slow hard disks that transferred less than 5 MB/s, not the high-speed devices of today. Flat ribbon cables have no insulation or protection from electromagnetic interference. Of course, these are reasons why the 80-conductor cable was developed for Ultra DMA. However, even with slower transfer modes there are limitations on how the cable can be used.

The main issue is the length of the cable. The longer the cable, the more the chance of data corruption due to interference on the cable and uneven signal propagation, and therefore, it is often recommended that the cable be kept as short as possible. According to the ATA standards, the official maximum length is 18 inches, but if you suspect problems with your hard disk you may find that a shorter cable will eliminate them. Sometimes moving where the disks are physically installed in the system case will let you use a shorter cable

Warning: There are companies that sell 24" and even 36" IDE cables. They are not recommended because they can lead to data corruption and other problems. Many people use these with success, but many people do a lot of things they shouldn't and get away with it. :^)

Ultra DMA (80-Conductor) IDE/ATA Cables (http://www.pcguide.com/ref/hdd/if/ide/confCable80-c.html)

There are a lot of issues and problems associated with the original 40-conductor IDE cable, due to its very old and not very robust design. Unterminated flat ribbon cables have never been all that great in terms of signal quality and dealing with reflections from the end of the cable. The warts of the old design were tolerable while signaling speeds on the IDE/ATA interface were relatively low, but as the speed of the interface continued to increase, the limitations of the cable were finally too great to be ignored.

that "upgrade happened at 66MB/s burst, we are now at the same speed as the PCI bus for burst rates 133MB/s

Fancy IDE leads - The Terrible Truth (http://www.dansdata.com/rcables.htm)

The spec mandates such short cables for two reasons.

Reason one - practically all IDE cables are unshielded. There's nothing around the conductors but insulation. Electromagnetic radiation goes straight through insulation. So external interference from the rest of your computer's giblets can influence the signal on your IDE leads.

Unshielded cables act like antennas. Generally speaking, the longer you make 'em, the more energy they can pick up from their environment.

Reason two - IDE cables are unterminated. "Termination", in the electrical sense, is essential to provide "impedance matching", which in English is what you have to do to stop the signal from reflecting off the end of the cable like a wave that hits the end of a bathtub.

Electric current does not move instantaneously down a wire. It travels at nearly the speed of light, but when you've got thirty-three and a third million clock pulses per second - which is the speed of the IDE bus - even light in a vacuum only moves a hair under nine metres per clock pulse.

So if you're fooling around with, say, a double-the-rated-length 900mm IDE lead, there's an end-to-end signal delay in it of about a tenth of a clock pulse. The signals you want your drives and your motherboard to be able to hear will be significantly blurred by delayed reflections from each end of the cable.

Transfer your data at twice or three times the UDMA/33 speed - as UDMA/66 and 100 do - and reflected signals get more and more out of step with the real signal, and do it more and more harm.

IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur (http://support.microsoft.com/default.aspx?scid=kb;en-us;817472)

Serial ATA and the 7 Deadly Sins of Parallel ATA (http://www.lostcircuits.com/advice/sata150/3.shtml)
Critical Limiting Factors in Parallel Design
There are some fundamental differences between serial and parallel buses, more importantly, there are some critical limiting factors in the design and implementation of any parallel bus.

1. Non-Interlocked (source synchronous) clocking
2. 3.3 V high-low signaling with 5V legacy tolerance
3. Cabling constraints
4. Connector legacy
5. Termination
6. Command queuing
7. PCB Design

3. Cable Design Issues: Cross-Talk and Ground Bouncing vs.Ringing

Each signal propagating through a data line makes the data line act like the inductor of a transformer. That is, each voltage swing generates a dynamic electromagnetic field, that, depending on cable length and proximity will induce another signal in adjacent data lines. This cross-talk adds noise to data lines and can produce errors by generating false positives or negatives simply by induction of voltage swings in data lines.

Another problem with parallel pathways is the phenomenon of simultaneously switching outputs (SSO) noise. As we explained in detail in our reviews of the i845 and the SIS645 chipsets, SSO noise becomes really problematic if the majority of signals switch from high to low since this can induce ground bouncing. On the chipset level, workaround in form of dynamic bus inversion (DBI) is feasible, that is, instead of switching all bits, only the reference bit is switched simultaneously at the sender and receiver end which has the same net effect, namely, that the system does not see the reference switch but thinks that all other lines have switched. DBI, however requires an additional latency cycle and this is where the 40 ns clock cycle time starts to look really ugly.

ATA not so Frequently Asked Questions
Or: Why Ribbon Cables are unsuitable for RF transmission of data (http://www.lostcircuits.com/advice/atafaq/)

The following article was written by snn47 to address some of the issues associated with standard ribbon cables and the use of e.g. removable drive racks as an attempt to share some insight into factors that can adversely affect the life or reliability of of desktop Hard Disk Drives. Specifically, issues like why some drives are working in some systems and not in others, the impact of cable routing and why is it that the drive manufacturers always recommend using their own cables (if supplied with the drive). (emphasis mine)

Any RF system has a limited tolerance for distortion of signals, which, in the worst case, can destroy some of the semiconductor components. While a certain amount of variation is part of any systems specification, one needs to remember that ATA was never intended to handle today's data rates. ATA or Advanced Technology Attachment started as the usual run of the mill or: "just a system at the lowest possible price point that will work most of the time without the need for huge financial investments". The problems started when the system was forced to handle higher and higher clock and data rates within the original design limitations. Keep in mind that the latest ATA-PI7 specifications allow data rates of 133 MB/sec, which is 44-times faster than the original ATA transfer of 3 MB/sec. This increase in speed makes it necessary to enforce minimum tolerances and detailed specifications to allow for the manufacturing of affordable systems with minimum compatibility problems.


these are just a few excerpts, I would highly advice that everyone give them a good read, there ARE good rounded ATA cables RD3XP Super Shielded (http://www.ioss.com.tw/web/English/RD3XPGladiator.html)
"RD3XP is made from ATA 100/133 High impedance flat cable cut into 8 layers of 10 cable wires, with a ground wire and signal wire alternatively, and folded in zigzag-piled so that each signal wire is surrounded by 4 ground wires."

but like their SCSI counterparts, they aint cheap, there are also high quality flat cables (you buy a $300 RAID card, and they dont ship you crappy PVC cables, they are either Teflon or Thermoplastic Olefin (TPO) (http://www.granitedigital.com/catalog/pg06_incable.htm)

Up until a little while ago I would have said ant investment made in high quality cables was money well spent, however with the introduction of SATA, that doesnt necessarily hold true anymore
unless your dealing with critical data (in which case you should be running ECC RAM) or your actually experiencing problems

a further excerpt from ATA not so FAQs

Preliminary Conclusions and Possible Cure

Reasons for changes in the propagation impedance, cross-coupling between adjacent signal wires and signal-velocity from one setup to another are :

Impedance of the drive and controller in high/low signal level will be different for different models.
Reflection of signals that garble the pulse, due to incorrect termination impedance or impedance-inconsistencies from the controller to the drive meaning the Impedance from the controller and the drive(s) differ.


If there is a a second drive (connector present/connected) the impedance will fluctuate at this point.

A. Only one HDD per controller channel.

B. Use a cable with only 2 connectors.

-Signal delay will increase with the length of the flat-ribbon-cable propagation of the signals were intended for a max. flat-ribbon-cable length of 18" with ~ 5ns/m would be 2.3ns delay.

C. shorten the cable whenever possible.

D. If the case requires long cables consider mounting just the HDD closer to the connectors of the controller or consider exchanging the usual desktop case, for a 19" case. Mount the HDD just above or below the PCB-controller-connector to allow you to reduce the length of the flat-ribbon-cable to a few cm.

Flat-ribbon-cable with different isolation material (higher/lower eR) and change in the conductor diameter will change the ratio of (2D/d).

Are rounded cable used?
E. Try exchanging the cable against another type/brand of flat-ribbon-cable.

Is the flat-ribbon-cable at some point parallel to a conducting grounded surface?
F. Try a different routing of your flat-ribbon-cable away from a ground-plane,

Was the cable cut apart and/or rolled it to get a rounded cable?
G. Unroll it and try B., if cut apart then start with A.

Is the drive mounted in a removable drive rack?
H. Remove HDD from the drive-bay and start with A.

However you should checkout the section in Dansdata's "IDE Fancy Leads, the terrible truth" as to why with all this goin on,
for the most part, it still works anyway :p

Check out what your chipset has to sort out here
http://www.vicstech.com/en/rd3xp/NoiseTest/
click on a picture to see an animated test
(note not all types of cables where employed, for instance there are no high quality TPO or teflon cables in this test)

like the Power Supply, cables are widely underated as a source of problems, and few ever spend any money on them for anything but "looks"
----------------------------------------------------------------------------------------------------------------------------

and

----------------------------------------------------------------------------------------------------------------------------
Integrity Testing

USING ATACT (edited into the top, follies follow :p )

well this is how I did it, and it was only employed on my PATA onboard channels
so for IDE Cards or RAID Channels, SATA ports, youll have to blunder around yourself :p

download ATACT (http://www.ata-atapi.com/atact.htm) demo
extract and change the .ug files to .txt files and read them
Download Dr DOS (http://www.bootdisk.com/)
run it and it will extract to a new floopy
access the floppy and remove the CONFIG.SYS file
(if you employ an MS-DOS boot disk you also need to remove the AUTOEXEC.BAT)
then add the ATACT.EXE file to it

reboot and change your boot order to floopy first if it isnt already
I was prompted to enter the Date and Time (???)
and then given an A:/ prompt
I always check the directory at that point (just to be sure)
A:/DIR which looked OK so
A:/ATACT P0 = runs on Primary Channel Device Zero (Master)
A:/ATACT P1 = runs on Primary Channel Device One (Slave)
A:/ATACT P01 = runs on Primary Channel Both Devices
A:/ATACT S0 = runs on Secondary Channel Device Zero (Master)
A:/ATACT S1 = runs on Secondary Channel Device One (Slave)
A:/ATACT S01 = runs on Secondary Channel Both Devices

there are lots of other switches, troubleshooting and modes
but I havent tried them, so Good Luck

another way to test data integrity is to copy and transfer it between partitions, drives, arrays, and computers, then run a checksum on the both sets of files to compare them, they should match
a very good freeware checksum is Fsum by slavasoft (http://www.slavasoft.com/fsum/)
Possibility to calculate a file message digest and/or a checksum using any of the 12 well-known and documented hash and checksum algorithms: MD2, MD4, MD5, SHA-1, SHA-2( 256, 384, 512), RIPEMD-160, PANAMA, TIGER, ADLER32, CRC32;

however since IDE covers up errors and resends them, while this will reveal if the data has been transfered without error, it wont verify that the data signaling is optimized, actual errors are pretty rare, so even a few are a sign something is wrong, in my personal experience various compressed archives seem to be more suceptible to corruption than a normal file, data corruption can strike any backup or redundancy strategy, so its important to test, and on occassion retest, when you need to restore important data isnt the time to find out its corrupted

Good Luck, and have fun.
-------------------------------------------------------------------------------------------------------------------------------

and I'll leave you with this indicative if less than thourgh review
http://reviews.pimprig.com/miscellaneous/rd3xp_gladiator_ata133_cables.php
sorry the alarmclock says I have to go to work

the best way I have found to determine if a cable is really good is to attach it to my RAID card which actually seems to log CRC errors (SX6000)

again from Fancy IDE leads - The Terrible Truth
CRC will always catch a one-bit error in a given data block. But if more than one bit's wrong, the CRC data may end up the same as it'd be if everything were fine.

That's not at all likely to happen to any given block of data, but in a system with a serious data corruption problem it certainly can happen rather often. Hard drives move a lot of blocks per day.

If data errors get through, you'd better hope there's something working at a higher level than the hardware CRC to catch the error. If nothing does, then the dud data gets written to the hard drive or to your memory. Which will give you corrupt data on the drive and/or a crash, depending on which way the data block was going and what it was for.

Even if no errors that actually get past the checking process, you still don't want a high error rate, because it slows down your drives. CRC only provides error detection, not error correction; to get the correct version of data, blocks with errors have to be sent again.

This means that long or just plain lousy cables may give you better drive performance if you lock the appropriate IDE channel to a slower transfer mode in your computer's BIOS setup. The theoretical available bandwidth is then lower, but if the error rate drops from "tons" to "not many" because you've now got the system running below the IDE cable's threshold of crumminess (a technical term), the net result can be better drive speed.

Want more ways to make things go wrong? Here's one. If you're overclocking your PCI bus - as many motherboards do, if you ask for a higher than normal processor Front Side Bus speed - then you're overclocking your IDE bus as well.

Overclocking the IDE bus is fine as long as it doesn't cause any more errors, but if your cable's borderline already - as it will be if it's greatly over-length - then clocking the bus a bit higher may be just enough to tip the system into real harmful errors.

What are such errors going to do to you, exactly?

Glad you asked.
Bit rot

If you've got a major IDE data loss problem, things will be obviously broken. Drives won't be recognised consistently (or at all) on boot, every file operation of any significant size will cause errors, swap file activity will hang the computer.

That's not the kind of problem you're likely to have from a common-or-garden over-length cable, though. When bits only fall on the floor relatively occasionally, the drives will not obviously be the culprit. If the hardware error detection's catching almost all of the foul-ups, all you'll see is strangely slow drive performance. Since drive speed has little impact on most desktop computer tasks, you probably won't notice.

The most heavily accessed part of your drive is very probably going to be the part that holds your Windows swap file. Since the swap file is literally part of your computer's random access memory as far as Windows is concerned, IDE data integrity problems can cause the same sorts of symptoms as faulty RAM.

Many of these symptoms don't look like drive errors at all. Swap file errors won't give you a disk error warning message; your computer will just jam its head enthusiastically up its cloaca and start chewing like mad. If you don't suspect the drive cable, you will then get to spend a significant fraction of your life cursing at the thing and swapping out perfectly OK components, to no avail.

A computer in this state can give the user the "anti-Midas touch" - everything you touch can turn to dung. Any write operation may, or may not, result in small but file-killing errors.

Oh, yes - what's the second-most-accessed single chunk of disk space on a Windows box? Probably the registry, baby. You don't want errors there, either.

[Eyeball Kid]

Next time, could you give me a longer answer? That is one big reply, thanks. I almost wish I hadn't asked, it's just one more thing to fidget and worry about on my machine...


DMA Mode for ATA/ATAPI Devices in Windows XP (http://www.microsoft.com/whdc/device/storage/IDE-DMA.mspx)



however that doesnt actually seem to be the case
(from Corruption 101 (http://hardforum.com/showthread.php?t=761272)

----------------------------------------------------------------------------------------------------------------------------
Cables

there is definately a reason why SATA is being adopted, ATA\IDE\EIDE\ATAPI (http://www.ata-atapi.com/hist.htm) is an unterminated standard and as speeds increase that causes more and more problems, especially if cheap cables are employed, complex device configurations, hotswap\removable drivebay bridgecards and poor cable routing

a few (:p) links and excerpts:
Standard (40-Conductor) IDE/ATA Cables (http://www.pcguide.com/ref/hdd/if/ide/confCable-c.html)

In many ways, the cable is the weak link in the IDE/ATA interface. It was originally designed for very slow hard disks that transferred less than 5 MB/s, not the high-speed devices of today. Flat ribbon cables have no insulation or protection from electromagnetic interference. Of course, these are reasons why the 80-conductor cable was developed for Ultra DMA. However, even with slower transfer modes there are limitations on how the cable can be used.

The main issue is the length of the cable. The longer the cable, the more the chance of data corruption due to interference on the cable and uneven signal propagation, and therefore, it is often recommended that the cable be kept as short as possible. According to the ATA standards, the official maximum length is 18 inches, but if you suspect problems with your hard disk you may find that a shorter cable will eliminate them. Sometimes moving where the disks are physically installed in the system case will let you use a shorter cable

Warning: There are companies that sell 24" and even 36" IDE cables. They are not recommended because they can lead to data corruption and other problems. Many people use these with success, but many people do a lot of things they shouldn't and get away with it. :^)

Ultra DMA (80-Conductor) IDE/ATA Cables (http://www.pcguide.com/ref/hdd/if/ide/confCable80-c.html)

There are a lot of issues and problems associated with the original 40-conductor IDE cable, due to its very old and not very robust design. Unterminated flat ribbon cables have never been all that great in terms of signal quality and dealing with reflections from the end of the cable. The warts of the old design were tolerable while signaling speeds on the IDE/ATA interface were relatively low, but as the speed of the interface continued to increase, the limitations of the cable were finally too great to be ignored.

that "upgrade happened at 66MB/s burst, we are now at the same speed as the PCI bus for burst rates 133MB/s

Fancy IDE leads - The Terrible Truth (http://www.dansdata.com/rcables.htm)

The spec mandates such short cables for two reasons.

Reason one - practically all IDE cables are unshielded. There's nothing around the conductors but insulation. Electromagnetic radiation goes straight through insulation. So external interference from the rest of your computer's giblets can influence the signal on your IDE leads.

Unshielded cables act like antennas. Generally speaking, the longer you make 'em, the more energy they can pick up from their environment.

Reason two - IDE cables are unterminated. "Termination", in the electrical sense, is essential to provide "impedance matching", which in English is what you have to do to stop the signal from reflecting off the end of the cable like a wave that hits the end of a bathtub.

Electric current does not move instantaneously down a wire. It travels at nearly the speed of light, but when you've got thirty-three and a third million clock pulses per second - which is the speed of the IDE bus - even light in a vacuum only moves a hair under nine metres per clock pulse.

So if you're fooling around with, say, a double-the-rated-length 900mm IDE lead, there's an end-to-end signal delay in it of about a tenth of a clock pulse. The signals you want your drives and your motherboard to be able to hear will be significantly blurred by delayed reflections from each end of the cable.

Transfer your data at twice or three times the UDMA/33 speed - as UDMA/66 and 100 do - and reflected signals get more and more out of step with the real signal, and do it more and more harm.

IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur (http://support.microsoft.com/default.aspx?scid=kb;en-us;817472)

Serial ATA and the 7 Deadly Sins of Parallel ATA (http://www.lostcircuits.com/advice/sata150/3.shtml)
Critical Limiting Factors in Parallel Design
There are some fundamental differences between serial and parallel buses, more importantly, there are some critical limiting factors in the design and implementation of any parallel bus.

1. Non-Interlocked (source synchronous) clocking
2. 3.3 V high-low signaling with 5V legacy tolerance
3. Cabling constraints
4. Connector legacy
5. Termination
6. Command queuing
7. PCB Design

3. Cable Design Issues: Cross-Talk and Ground Bouncing vs.Ringing

Each signal propagating through a data line makes the data line act like the inductor of a transformer. That is, each voltage swing generates a dynamic electromagnetic field, that, depending on cable length and proximity will induce another signal in adjacent data lines. This cross-talk adds noise to data lines and can produce errors by generating false positives or negatives simply by induction of voltage swings in data lines.

Another problem with parallel pathways is the phenomenon of simultaneously switching outputs (SSO) noise. As we explained in detail in our reviews of the i845 and the SIS645 chipsets, SSO noise becomes really problematic if the majority of signals switch from high to low since this can induce ground bouncing. On the chipset level, workaround in form of dynamic bus inversion (DBI) is feasible, that is, instead of switching all bits, only the reference bit is switched simultaneously at the sender and receiver end which has the same net effect, namely, that the system does not see the reference switch but thinks that all other lines have switched. DBI, however requires an additional latency cycle and this is where the 40 ns clock cycle time starts to look really ugly.

ATA not so Frequently Asked Questions
Or: Why Ribbon Cables are unsuitable for RF transmission of data (http://www.lostcircuits.com/advice/atafaq/)

The following article was written by snn47 to address some of the issues associated with standard ribbon cables and the use of e.g. removable drive racks as an attempt to share some insight into factors that can adversely affect the life or reliability of of desktop Hard Disk Drives. Specifically, issues like why some drives are working in some systems and not in others, the impact of cable routing and why is it that the drive manufacturers always recommend using their own cables (if supplied with the drive). (emphasis mine)

Any RF system has a limited tolerance for distortion of signals, which, in the worst case, can destroy some of the semiconductor components. While a certain amount of variation is part of any systems specification, one needs to remember that ATA was never intended to handle today's data rates. ATA or Advanced Technology Attachment started as the usual run of the mill or: "just a system at the lowest possible price point that will work most of the time without the need for huge financial investments". The problems started when the system was forced to handle higher and higher clock and data rates within the original design limitations. Keep in mind that the latest ATA-PI7 specifications allow data rates of 133 MB/sec, which is 44-times faster than the original ATA transfer of 3 MB/sec. This increase in speed makes it necessary to enforce minimum tolerances and detailed specifications to allow for the manufacturing of affordable systems with minimum compatibility problems.


these are just a few excerpts, I would highly advice that everyone give them a good read, there ARE good rounded ATA cables RD3XP Super Shielded (http://www.ioss.com.tw/web/English/RD3XPGladiator.html)
"RD3XP is made from ATA 100/133 High impedance flat cable cut into 8 layers of 10 cable wires, with a ground wire and signal wire alternatively, and folded in zigzag-piled so that each signal wire is surrounded by 4 ground wires."

but like their SCSI counterparts, they aint cheap, there are also high quality flat cables (you buy a $300 RAID card, and they dont ship you crappy PVC cables, they are either Teflon or Thermoplastic Olefin (TPO) (http://www.granitedigital.com/catalog/pg06_incable.htm)

Up until a little while ago I would have said ant investment made in high quality cables was money well spent, however with the introduction of SATA, that doesnt necessarily hold true anymore
unless your dealing with critical data (in which case you should be running ECC RAM) or your actually experiencing problems

a further excerpt from ATA not so FAQs

Preliminary Conclusions and Possible Cure

Reasons for changes in the propagation impedance, cross-coupling between adjacent signal wires and signal-velocity from one setup to another are :

Impedance of the drive and controller in high/low signal level will be different for different models.
Reflection of signals that garble the pulse, due to incorrect termination impedance or impedance-inconsistencies from the controller to the drive meaning the Impedance from the controller and the drive(s) differ.


If there is a a second drive (connector present/connected) the impedance will fluctuate at this point.

A. Only one HDD per controller channel.

B. Use a cable with only 2 connectors.

-Signal delay will increase with the length of the flat-ribbon-cable propagation of the signals were intended for a max. flat-ribbon-cable length of 18" with ~ 5ns/m would be 2.3ns delay.

C. shorten the cable whenever possible.

D. If the case requires long cables consider mounting just the HDD closer to the connectors of the controller or consider exchanging the usual desktop case, for a 19" case. Mount the HDD just above or below the PCB-controller-connector to allow you to reduce the length of the flat-ribbon-cable to a few cm.

Flat-ribbon-cable with different isolation material (higher/lower eR) and change in the conductor diameter will change the ratio of (2D/d).

Are rounded cable used?
E. Try exchanging the cable against another type/brand of flat-ribbon-cable.

Is the flat-ribbon-cable at some point parallel to a conducting grounded surface?
F. Try a different routing of your flat-ribbon-cable away from a ground-plane,

Was the cable cut apart and/or rolled it to get a rounded cable?
G. Unroll it and try B., if cut apart then start with A.

Is the drive mounted in a removable drive rack?
H. Remove HDD from the drive-bay and start with A.

However you should checkout the section in Dansdata's "IDE Fancy Leads, the terrible truth" as to why with all this goin on,
for the most part, it still works anyway :p

Check out what your chipset has to sort out here
http://www.vicstech.com/en/rd3xp/NoiseTest/
click on a picture to see an animated test
(note not all types of cables where employed, for instance there are no high quality TPO or teflon cables in this test)

like the Power Supply, cables are widely underated as a source of problems, and few ever spend any money on them for anything but "looks"
----------------------------------------------------------------------------------------------------------------------------

and

----------------------------------------------------------------------------------------------------------------------------
Integrity Testing

USING ATACT (edited into the top, follies follow :p )

well this is how I did it, and it was only employed on my PATA onboard channels
so for IDE Cards or RAID Channels, SATA ports, youll have to blunder around yourself :p

download ATACT (http://www.ata-atapi.com/atact.htm) demo
extract and change the .ug files to .txt files and read them
Download Dr DOS (http://www.bootdisk.com/)
run it and it will extract to a new floopy
access the floppy and remove the CONFIG.SYS file
(if you employ an MS-DOS boot disk you also need to remove the AUTOEXEC.BAT)
then add the ATACT.EXE file to it

reboot and change your boot order to floopy first if it isnt already
I was prompted to enter the Date and Time (???)
and then given an A:/ prompt
I always check the directory at that point (just to be sure)
A:/DIR which looked OK so
A:/ATACT P0 = runs on Primary Channel Device Zero (Master)
A:/ATACT P1 = runs on Primary Channel Device One (Slave)
A:/ATACT P01 = runs on Primary Channel Both Devices
A:/ATACT S0 = runs on Secondary Channel Device Zero (Master)
A:/ATACT S1 = runs on Secondary Channel Device One (Slave)
A:/ATACT S01 = runs on Secondary Channel Both Devices

there are lots of other switches, troubleshooting and modes
but I havent tried them, so Good Luck

another way to test data integrity is to copy and transfer it between partitions, drives, arrays, and computers, then run a checksum on the both sets of files to compare them, they should match
a very good freeware checksum is Fsum by slavasoft (http://www.slavasoft.com/fsum/)


however since IDE covers up errors and resends them, while this will reveal if the data has been transfered without error, it wont verify that the data signaling is optimized, actual errors are pretty rare, so even a few are a sign something is wrong, in my personal experience various compressed archives seem to be more suceptible to corruption than a normal file, data corruption can strike any backup or redundancy strategy, so its important to test, and on occassion retest, when you need to restore important data isnt the time to find out its corrupted

Good Luck, and have fun.
-------------------------------------------------------------------------------------------------------------------------------

and I'll leave you with this indicative if less than thourgh review
http://reviews.pimprig.com/miscellaneous/rd3xp_gladiator_ata133_cables.php
sorry the alarmclock says I have to go to work

the best way I have found to determine if a cable is really good is to attach it to my RAID card which actually seems to log CRC errors (SX6000)

again from Fancy IDE leads - The Terrible Truth

[Bookmage]

:eek: :eek: :eek:

I suppose that's why he's a super moderator....

Lots of info....
Where to get good quality flat cables than? What about Round cables?

[Ice Czar]

for flat cables search for teflon or TPO Thermoplastic Olefin
for round Id recommend the IOSS Gladiator RD3XP actually Id recommend them above flat cables

teflon (http://froogle.google.com/froogle?q=teflon+IDE+cable&as_qdr=)
ideally 18 inches or shorter, single connector better than double but a dual if you must
TPO (http://froogle.google.com/froogle?q=TPO%20IDE%20cable&hl=en&lr=&sa=N&tab=wf)


and
http://www.paragonca.com/rd3xpgladiator.html
for the RD3XP $10 to $15 (cheap compared to SCSI externals :p )

again the few connectors and shorter the better
but get what you need