Reposted from one of the previous posts I made on rounded cables on this forum:
The maximum cable length you're meant to use for any ATA interface - any kind of modern "IDE" drive - is 457mm, according to the official specification. That's 18 inches. This length limit applies to 40 and 80-wire cables alike. 80 wire cables also can't be any shorter than 254mm (ten inches), by the way. The 18 inch limit is why IDE is an internal-drives-only interface. You can run the cable out of your PC's case if you like, but it won't get far. 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.
SCSI works with long unshielded ribbon cables because it puts terminators at either end. IDE doesn't have 'em.
That's most what you need to know about lengths. For those who want to know why the shielding such as that in the ioss cables is important, or those simply with a quest for knowledge, read on.
The faster the transfer mode your drives use, the more susceptible they'll be to cable problems, all other things being equal. That's why the 80 wire cable standard for UDMA/66 and UDMAA/100 exists at all; it makes the cables less error-prone. Each end of an 80 wire IDE cable has only 40 terminals. The extra interleaved wires are all earths, electrically tied together at each end.
The earths are actually something of a blast from the past. Back in the mists of time when ATA was first conceived, it was an eight bit parallel interface with interleaved ground wires. Just like the modern 80 wire cables, only not as many wires.
Not much later, the wires that started out assigned to ground duty got converted into more data wires, to give the interface 16 bit data width with minimum retooling. That played hob with the electrical characteristics of the cables, but at the low speeds of the early PIO ATA modes, it wasn't a tremendously big deal to get acceptable data clarity.
A ribbon cable with interleaved earths has easily characterised impedance - you can put your finger on how much it will resist the passage of alternating current, like a data signal. It's much easier to send an electrical signal from one device to another if the impedance of the devices, and of the connecting cable, is known. It's possible to design a setup that adapts to impedance mismatches, but it's much cheaper and simpler to match the impedance properly. Well, it is if you've got a decent cable design, anyway.
With interleaved earths, each signal wire interacts very little with the signal wires on either side. The electromagnetic and electrostatic fields from the signal wires get eaten by the earths in between them. Remove the earths, and the cable impedance can vary tremendously - apparently, by a factor of two or three - depending on what wires are and aren't energised at what moment.
IDE device designers don't know how the cable's going to be routed - whether it's going to be hanging in the middle of a case away from the chassis metalwork, or tightly clamped to the side of the case, or some mixture of both. This determines the cable's capacitance to earth - since the PC case is earthed - and that also influences impedance.
In brief, if the impedance is lower than the "driver" circuitry that's trying to send a signal expects, then the driver will be unable to deliver enough current at full signal voltage, the signal strength will thus fall, and you're on your way to data loss. Data-signal drivers have much less trouble feeding high impedance loads - but when the impedance of a 40 wire cable rises for whatever reason, the impedance of the drive on the end of it doesn't. That creates an impedance mismatch at the end, which causes signal reflection problems. Ideally, you don't want the impedance of the cable to vary at all. And interleaving earths among the signal wires does a pretty good job of squishing the impedance fluctuations.
So what happens when you take an 80 wire interleaved-earth ribbon cable, split it into individual wires, and bundle 'em up?
Look under the rubber boot on one of these things and the wires are bundled in neatly enough, but the mixture of data and earth wires is all higgledy-piggledy. If you want to reduce the nasty gang-of-wires effects that happen when particularly inopportune combinations of wires are energised and not energised then mixing the wires up all over the place may well help. If you want a tightly characterised cable, though, I can't help but think that explosion-in-a-spaghetti-factory wiring like this is not going to give you one.
What may be causing you a certain amount of confusion at this juncture is the fact that there are people all over the world successfully using over-length ATA cables. Including round ones. Some people use cables 750mm or even 900mm in length, without causing any obvious explosions or outbreaks of smallpox. How so, I hear you ask.
Again, two reasons.
Reason one - good enough components at each end of the cable can deal with more signal corruption than the IDE specification demands of them. Modern ATA hardware is pretty darn good at dealing with lousy cables. Older drives typically have lower tolerances, and some older motherboard IDE chipsets did brilliant things like effectively connect the two IDE connectors together as far as length-related problems went, resulting in seven inch real world cable length limits if you attached cables to both connectors. But those days are largely past. Current consumer IDE hardware can shout through the noise quite well.
Reason two - IDE covers up data loss problems. The ATA interface has CRC error checking built in. When data's munged in transit down the cable, the error is detected and the data is resent.
Well, it usually is.
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?
What, you're STILL reading? Man, you're a die-hard. By this point, you know that overclocking a PCI bus can overclock an IDE bus as well, and that's a BIG no-no (but, most overclockers are smart enough to buy mobos with a PCI/AGP lock so when overclocking their FSB, they don't get their PCI/AGP/IDE bus as well. But, let's say you're a bit daft (you have been reading this a rather long time, you know). Let's look at those errors:
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.
EDIT: Which is why I've stated before, if using rounded cables, I would only ever use IOSS RD3XP Gladiators because a) shielded on the outside with a ground wire for the drive cage, and b) made up of multiple layers of alternating grounds / live wires, and shielding with foil between layers. Thus, preserving the original IDE flat ribbon-cable layout. Every other rounded cable that I know of that claims "shielded" is talking about an outside shielding, but now all the wires are bundled together so they are in practice UNSHIELDED and also do away with being an 80-wire cable in affect.
I have a list of sites that tested them on the web (something like 6 or so hardware testing sites), and on the EXACT same setup, the IOSS cables improved transfers anywhere from 4 to 15% over ribbon cables, and other rounded cables were much WORSE than flat ribbon cables, actually slowing down transfers because of data corruption.
Facebook
Twitter