The IDE interface originated back in the late '80s and has, as one would expect, evolved over time. Physically it started off life as a 40-pin connector and subsequently included a 44-pin connector as used in laptops - the extra pins being used to provide power for the attached drive and so removing the need for a separate power connector.
The data transfer protocol has also developed over time. Originally there were various PIO modes that offered transfer speeds from 3.3MB/s through to 16.7MB/s. These days we have various UDMA modes that offer transfer speeds from 16.7MB/s through to 167MB/s.
Hand-in-hand with the increase in data transfer speeds comes the greater importance of the transmission characteristics of the connection between the motherboard and the remote device and one significant factor is crosstalk. Crosstalk is where, thanks to the capacitive coupling between the data lines, the signal on one data line affects its immediate neighbours.
The magnitude of the crosstalk increases with the length of the connecting cable and the frequency (signalling rate) of the signals. If sufficiently large the interference will cause data transmission errors.
The crosstalk issue was addressed by the introduction of an extra earthed conductor between each data line to isolate them from each other. The connecting ribbon cables now became 80-way cables but the actual connectors remained as 40-way. Hand-in-hand with the introduction of the 80-way cable the standard included a method of identifying the fact that an 80-way cable was fitted.
If the IDE driver doesn't detect an 80-way cable then it assumes that a long 40-way ribbon cable is fitted and restricts the maximum transfer speed to 33 MiB/s (UDMA2 / ATA4).
Some Thin Clients (eg IGEL Winestra) use Compact Flash cards for their flash memory. In these cases there is no connecting cable as the sockets are mounted directly on the motherboard.
There are also Compact Flash-to-IDE adaptors that some people use to replace/upgrade the flash memory in Thin Clients. (There are also similar adaptors these days that allow SD cards to be used). These adaptors are usually used with a very short 40-way cable to connect it to the IDE interface.
In each of these cases the IDE interface is capable of running at (much) higher speeds than the 'long 40-way cable' scenario. However, as the signalling mechanism is '80-way cable yes/no', the 'no' answer is taken to mean that it's a long 40-way cable in place and so the IDE driver defaults to a maximum safe standard of UDMA/33.
The original IDE interface standard limited the length of the ribbon cable to 18" (46cm). I guess a crude rule of thumb you can use as to the length of cable you need is that every time you halve the length of a 40-way cable you can double the transmission rate. (e.g. If your Compact Flash card can run at 100MB/s the 40-way cable has to be less than 15cm).
For those wishing to maximise the data transfer performance of their compact flash based thin client there are three factors to consider:
The details of (1) and (3) are dependant on you being able to track down the relevant data.
For example the data sheet on the AMD CS5536 says:
The CS5536 companion device is compliant to the ATA-6 specification. The IDE interface supports one channel, that in turn supports two devices that can operate in PIO modes 0 to 4, MDMA modes 0 to 2, or UDMA modes 0 to 5 (up to 100 MB/s).
...so no UDMA6 with that then.
Early Compact Flash cards worked in PIO mode only but things have improved since then. A correspondent noted: "Modern CF cards can run a lot faster than UDMA2; the one I'm using in my thin client supports UDMA7.
My IGEL Winestra is fitted with a Transcend '80x' Compact Flash card. The datasheet on this says:
- Single Power Supply: 5V +/- 10% / 3.3V +/- 5%
- Support PIO mode 0 to PIO mode 6
- Support Multi-Word DMA mode 0 to Multi-Word DMA mode 4 (Series of -P only supports PIO mode 0 to mode 4, please see Ordering Information)
An old 8GB Kingston Compact Flash card falls into the 'unknown' category. Google did find me
something that called itself a 'datasheet', but that didn't say much more than:
This is a type II Compact Flash card.
Having made the comment above about datasheets I see that the basic information is actually reported by the Linux Kernel. See Example below. It turns out the Kingston card above is capable of UDMA/100.
Luckily we are able to override the default behaviour of Linux IDE drivers by passing command line parameters to the kernel when the system is booted. See here for a full list of kernel parameters.
The one of interest here is libata.force=short40c. This signals to the IDE driver that a short 40-way cable is being used and hence that there is no need to impose a maximum speed limit of UDMA/33.
Note: There are other optional parameters that you can use to apply the action to a specific IDE interface and, if needed, to a specific device on that interface. These are illustrated in the examples below.
A correspondent provided some examples:
The right port and device values can be identified by checking the output of the command:
sudo dmesg | grep -i " ata"
He added that an email exchange with a Transcend support person gave him some additional information:
CF cards must be able to operate at 3.3 volts to support UDMA6 and later standards, 5 volt CF cards can be unstable at more than UDMA5.
...and by extension Compact Flash sockets need to provide 3.3V to the cards that support UDMA6 and 7 in order to run them at those speeds.
When in doubt, or:
you need to limit the speed to UDMA5 or less.
He goes on to say:
The kernel doesn't give the option to say "max speed of the card but no more than UDMA5", so you need to specify the exact speed of your card.
For example in my 4210LX, my card supports UDMA7 but I'm not sure whether the socket provides 3.3V. So the maximum speed I can run my card at is UDMA5, and my kernel parameter is:
libata.force=1.00:short40c,udma5
These entries are from the dmesg output on an Igel 4210L
First we see the IDE interfaces and their capability:
... ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xeb00 irq 14 ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xeb08 irq 15 ...
...which shows the interface supports up to UDMA/133 (UDMA6) which ties up with the datasheet.
With the 'Transcend 80x' Compact Flash card fitted, further down the listing we find:
... ata1.00: ATA-0: TRANSCEND, 20071116, max MWDMA2 ...... shows the card can manage MWDMA2 (16.7Mb/s).
Changing the compact flash for 2GB Transcend 300x Compact Flash card we now see:
... ata1.00: CFA: TRANSCEND, 20100323, max UDMA/66 ... ata1.00: limited to UDMA/33 due to 40-wire cable ...
... so this 300x card is capable of UDMA/66 but has been restricted to UDMA/33 as no 80-way cable has been detected on the interface and so the driver has assumed that a long 40-way cable is being used.
If we add the command line parameter libata.force=short40c we now see:
... ata1: FORCE: cable set to short40c ata1.00: CFA: TRANSCEND, 20100323, max UDMA/66 ...... which shows the command line argument that was given to 'libata' (assume a short 40-way cable is being used) and there is no longer any mention of the transfer speed being limited to UDMA/33.
The original mention of the short40c parameter was provided by Craig Oakes
The expanded article was prompted by input from a correspondent who was pressing an IGEL 4210LX into service.