Talk:Parallel ATA

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Valent (talk | contribs) at 13:53, 10 October 2008. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives and page organization

Archives:

Archive Others (non-relevant to the article)


ATA standards versions, transfer rates, and features

The table says on ATA/ATAPI-7 (ATA-7, Ultra ATA/133) that there is SATA/150. But where is SATA/300 ? It is not listed. -- Frap 16:03, 01 October 2006 (UTC)[reply]

It's certainly in the Serial ATA article. I'm not sure why SATA/150 is in the table in this article at all. Jeh (talk) 09:36, 22 June 2008 (UTC)[reply]
AT/ATAPI doesn't describe physical interface anymore - it could be Parallel ATA, Serial ATA or eSATA (and FireWire or USB for that matter), and any ATA/ATAPI drive will still respond to commands defined by the ATA/ATAPI standard (what's more, Serial ATA can also be used to interconnect SCSI devices as in Serial Attached SCSI). --Dmitry (talk •contibs ) 21:13, 5 October 2006 (UTC)[reply]
But there is a standard describing the physical connection. As a practical matter a "parallel ATA device" still follows the physical connection standards described in ATA/ATAPI 6. Jeh (talk) 09:36, 22 June 2008 (UTC)[reply]

Suggested fix for picture of cables

On my monitor I can't see any difference between the "80 conductor cable" and the "40 conductor cable" (second picture), except that the connectors are colored. I think we should find a picture that better shows the different conductor spacing. All of you others, get right on that. ;) Seriously, I'll see if I can't take one myself. Jeh 09:19, 21 October 2006 (UTC)[reply]

Apparent error in the "cable select" section

I think this passage is confusing or inaccurate:

"With the 40-wire cable it was very common to implement cable select by simply cutting the pin 28 wire between the two device connectors. This puts the slave device at the end of the cable, and the master on the "middle" connector. This arrangement eventually was standardized in later versions of the specification. If there is just one device on the cable, this results in an unused "stub" of cable. This is undesirable, both for physical convenience and electrical reasons: The stub causes signal reflections, particularly at higher transfer rates."

I would've fixed it myself, but I'm not sure I understand it. If early users were hacking ribbon cables to have an open pin 28, that would only work by cutting between the second and third connection. This would put the master to the middle connector, as the passage says. It says this arrangement was standardized in later versions, but all the ATA ribbon cables I've seen put the black master connector at the end, and the gray slave in the middle. I think what the passage means to say is that these early hacks had the opposite configuration of modern cables, which just leave gray pin 28 with no wire contact. Someone who understands what this paragraph is trying to say should probably fix it so someone doesn't put their cables on backward. --Loqi T. 02:51, 7 June 2007 (UTC)[reply]

I read it as saying
  • The most common way of implementing cable select prior to the 80 conductor era (though cable select back then was bloody rare anyway) was to cut one wire between the two device connectors (that is between the master device and the slave device). This put the slave connector in the middle which was undesirable.
  • This was standardised in some later version of the ATA spec (not having read the spec I can neither confirm nor deny this), it would also be usefull to know which version.
The next paragraph then goes on to say that this was changed with the introduction of 80 conductor cables which do indeed put the master device at the end.
Personally I have never seen a 40 wire cable that supported cable select.
I've seen a few that indeed had a "hole" punched out of the pin 28 wire between the second and third connetions, just like used to be done on floppy cables. But not many. Jeh (talk) 13:22, 7 July 2008 (UTC)[reply]


windows limitations

according to http://discountechnology.com/Seagate-160GB-IDE-ATA-100-Hard-Drive:

  • windows 2000 up to sp3 have a limitation of 137 GB
  • windows xp up to sp1 have a limitation of 137 GB

so we could add it asomewhere
GNUtoo 12:50, 13 July 2007 (UTC)[reply]

Found some further info at seagate d17 sata product manual google cache in section 3.8.1:
W2000 Sp3 + XP Sp1 needs "Big Drive Enabler"
Maxtor Knowledge Base Answer ID 960
MS KB 303013
Electron9 23:59, 25 July 2007 (UTC)[reply]


Size limits - Win98 64GB

Good article, but too bad it does not list all the size boundaries. This article seems excellent, mentions the Win98 64GB boundary: [1] -69.87.199.99 19:53, 18 September 2007 (UTC)[reply]

I'm not sure that restrictions imposed by operating systems belong in an article about the ATA interface and standards, since the ATA interface and standards have nothing to do with these restrictions. Jeh (talk) 22:26, 22 June 2008 (UTC)[reply]
Maybe we need a page summarising the common PC storage size limits and what part of the system (hardware, bios, OS etc) imposed them. Then linking to the appropriate articles for further details. Plugwash (talk) 22:42, 23 June 2008 (UTC)[reply]

comparing IDE/ATA speed with others

The speed presented in this article is in MB/s, generally accepted as the abbreviation of Megabyte per second. In the SATA and USB aritcles the speed is presented in Mbits/s (Megabits per second). Could someone check the speed of ATA in Mbits/s please? it is possible it is alredy in megabits but somone did not write it properly. --Iamcon (talk) 07:01, 22 January 2008 (UTC)[reply]

The speeds quoted here are the correct numbers for megabytes/second (where mega = 1,000,000). For example, UDMA 5 runs at 100,000,000 bytes/second. I hope this is unambiguous enough.
The reason SATA and USB quote in bits per second is that they are serial protocols: one bit is sent at a time. Parallel ATA is not like that; it sends 16 data bits at a time. In each case these are the "natural" units, according to the respective technologies. They are also the same units and numbers quoted in industry standard specifications and sales information for these interfaces.
You can't just take the PATA number and multiply by eight to get a number comparable with serial protocols, either. SATA uses an encoding involving 10 bits on the wire for eight bits on the disk. The "1.5 Gbit/sec" figure for the original SATA is the bit rate on the wire, not on the disk, and translates to 120 megabytes/second of actual data read or written. USB uses a "bit-stuffing" protocol in which the ratio is not even constant. Jeh (talk) 07:32, 22 January 2008 (UTC)[reply]
Bits may be transferred by different means, it still boils down to effective transmission capacity per second. And associated latency. It's much harder to make comparisions when the same thing is noted in different units. Electron9 (talk) 15:02, 15 February 2008 (UTC)[reply]
The point I'm making is that "effective transmission capacity per second" is, at least, more accurate for PATA's "133 MB/sec", than for SATA's "1.5 Gb/sec": All issues of latency, inter-block delays, etc., aside, it is possible that there could be periods of time during which PATA would be transferring 133 MB/sec of end user data. This can't be said of SATA's "1.5 Gb/sec". Yes, switching units makes things even more confusing, but it would also be confusing to cite specs for these buses using units other than those commonly quoted. Adding corrections for e.g. 10 physical-layer bits to 8 transport-layer bits would simply compound the confusion, and would likely result in frequent "corrections" by new wiki editors who didn't stop to read the explanations.
I do think it would be worthwhile to "rationalize" all of these specs so that useful comparisons could be made (perhaps in a separate article pointed to by the PATA, SATA, USB, etc., articles), but this should be done in addition to, not instead of, cites of the "official" numbers using the usual units for each. Also it should be done with a LOT of explanation. Jeh (talk) 00:59, 16 February 2008 (UTC)[reply]
I suggest then to add a seperate value "effective transfer rate". Electron9 (talk) 07:12, 16 February 2008 (UTC)[reply]

apparent conflict between article page and other reference

From this article:

In Maximum security mode, you cannot unlock the disk! The only way to get the disk back to a usable state is to issue the SECURITY ERASE PREPARE command, immediately followed by SECURITY ERASE UNIT. The SECURITY ERASE UNIT command requires the Master password and will completely erase all data on the disk. The operation is rather slow, expect half an hour or more for big disks. (Word 89 in the IDENTIFY response indicates how long the operation will take.) [3] [4]

From the article in c't:

When setting his or her password the user can choose between the security levels "High" and "Maximum." When the level "High" is chosen the disk will accept either the user or the master password to unlock the disk or disable the protection function. When "Maximum" is the choice only the user password will provide access to the data. Should it get lost then the administrator with his or her master password will only be able to unlock the disk after forfeiting all the data stored upon it. Which step is accomplished by the command Security Erase: It erases all the information by writing zeros onto all sectors of the hard disk before again allowing access to it.

These seem contradictory.

Ealex292 (talk) 02:44, 28 April 2008 (UTC)[reply]

request for clarification on maximum security mode

OK...so this means once this mode is entered, the only way to use this other than a heater and doorstop is to erase the media and start again? I don't know the specification...do you mean instead "if the password is provided incorrectly too many times?

(comment text added by Rchandra to the article on 24 May 2008. Copied here by Jeh (talk) 19:15, 27 June 2008 (UTC)[reply]

Place Word DMA as stub

I propose we should integrated Word DMA as a stub article to Advanced Technology Attachment, anyone agrees? WDMA (computer) --Ramu50 (talk) 02:23, 7 July 2008 (UTC)[reply]

You mean merge it with this article? Maybe, but then the section containing that info should also explain the ATA PIO modes (merged from the article on PIO, which really needs to talk much more about PIO in general (eg to serial and parallel ports), right now it is too specific to ATA) and also the UDMA modes. Then you will have doubled the size of this article. Maybe instead, put all three of those into a separate article on "AT Attachment transfer modes". Otherwise I think the existing articles on PIO and WDMA should stay as they are, and an article on UDMA added. That can be an easy next step. Adding an article is always easier than merging. Jeh (talk) 13:09, 7 July 2008 (UTC)[reply]


"Technical criticisms" section

Upon comment by Ramu50 I agree, the "technical criticisms" section from the article counts as WP:OR as per WP:CRITICISM. I have moved it here until someone finds reliable sources that state these points as criticisms. Quoting the spec is not a source for a criticism as the conclusion that the spec is describing a problem is that of the WP editor. A blog is not even a reliable source and the blog entry cited does not support the contention that the ATA specification is at fault. It does criticize the default drive behavior of "write cache enabled" and the refusal of some OSs to allow this to be overridden, but neither is a problem of the ATA spec, nor specific to ATA drives. Jeh (talk) 03:51, 17 July 2008 (UTC)[reply]

Technical criticisms

Criticisms of current versions

The write cache of ATA disk drives is enabled by default to increase performance. If a power failure occurs before data in the write cache has been flushed to the disk, data will be lost. There is a "flush cache" command in ATA protocol, which will write the entire cache to medium before returning. However, the protocol does not allow a way to inquire a drive if a particular sector has been written or not.[1][2]

Criticisms of obsolete versions

ATA1 (section 9.22)[3], ATA2[4], ATA3[5] specifies 'Set Features' command allows the user to enable it if the drive shall 'Enable write cache,' but does not specify the command to flush the cache.

ATA4 (section 8.10)[6] specifies 'Flush Cache,' however should an error occur while executing the command, the disk will return the failing sector address and the sector is removed from cache. An alternative way to initiate flush cache does exist from ATA4 (section 8.37.9) and onwards: "When the subcommand disable write cache is issued, the device shall initiate the sequence to flush cache to non-volatile memory before command (see 8.10)."


Page moved

I moved the page, to agree with content.Bettering the Wiki (talk) 05:13, 17 September 2008 (UTC)[reply]

Thank you! The page was originally "AT Attachment", renamed to "Advanced Technology Attachment" by someone who did not realize that that is not the correct name. Since the "AT Attachment" page was now a redirect with more than one edit in its history this change could not be simply reverted. (I also tried going through "requested moves", arguing for "speedy revert of undiscussed move", to no avail.) So, uh... how did you do it? Thanks, regardless! Jeh (talk) 08:51, 19 September 2008 (UTC)[reply]

Hot-pluggability

To the editor who keeps putting "hot-pluggable: yes, with software" back into the article:

Sure, you can put a filter driver on top of just about any device to make it "hot pluggable at the software level." However the article describes ATA as described in the ATA standards docs. The specifications describe, among other things, the hardware interface - the electrical characteristics of the signals and the mechanical characteristics of the connectors. And these aspects of ATA simply do not permit ATA devices to be safely hot-plugged.

A hot-pluggable device interface has many well known characteristics. Typically the contacts are staggered and the connector designed so that upon connection ground mates first, then power, then the data signals. ATA is not like that and as a result you stand a good chance of electrically damaging either the device or the host interface if you try it. PATA does not even have power and signals on the same connector (except in the laptop 44 pin version), or on mechanically linked connectors as far as the cable side is concerned, so cannot make any guarantees about make or break sequencing.

There is nothing that any software can do about this.

Yes, there are of course "mobile racks" and similar things that work around this, mostly by mechanically requiring that the drive be powered off during insertion or removal. But they are not covered or allowed for by the ATA spec; in fact, they violate it, as the ATA spec does not allow for any "intermediate" connectors between the host controller and the device. The fact that these devices sometimes do work (and, in my direct experience, sometimes not) is beside the point; the article is referenced to the PATA specs.

I hope this clarifies the issues involved. Jeh (talk) 08:57, 19 September 2008 (UTC)[reply]

Laptop 44 pin ATA connector

There should he pinout and picture of laptop 2.5" 44 pin connector

Notes and references

  1. ^ "T10/05-239r0 SAT - Caching mode page" (PDF). 070716 t10.org
  2. ^ "The story of the write cache and half a worm". 070716 java.net
  3. ^ "X3.221-1994" (PDF). 070719 ftp.t10.org
  4. ^ "X3T10/0948D Information Technology - AT Attachment Interface with Extensions (ATA-2)" (PDF). 070719 t10.org
  5. ^ "X3T13 2008D Information Technology - AT Attachment-3 Interface (ATA-3)" (PDF). 070719 t10.org
  6. ^ "T13 1153D Information Technology - AT Attachment with Packet Interface Extension (ATA/ATAPI-4)" (PDF). 070719 t10.org
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Parallel_ATA&oldid=244370616"