This message is from the T13 list server.
Pat, Actually, this goes all the way back to ATA-1: 9.21 SEEK This command initiates a seek to the track and selects the head specified in the command block. The drive need not be formatted for a seek to execute properly. See 10.3 for protocol. The drive shall not set DSC=1 until the action of seeking has completed. The drive may return the interrupt before the seek is completed. If another command is issued to the drive while a seek is being executed, the drive sets BSY=1, waits for the seek to complete, and then begins execution of the command. Microsoft's behavior sounds like the sort of thing you would do with this SEEK command. Since the interrupt for the command is returned immediately, the only way to see if the seek has actually completed is to poll the DSC bit (which appears to be what they are doing). That's a good reason why people did not really like this approach - but it was all they had until 5 years ago. Any drive that implements command queuing implements overlapping (since the latter is a subset of the former). Some drives implement queuing today. The problem has always been, as you indicated, more with the Microsoft support of ATA command queuing rather than the drives per se (if Microsoft supported it everyone would have it ASAP). I'm surprised that ATAPI devices don't use it, since the original overlap proposal was presented as an ATAPI proposal (since CDs can hog the bus for a long time while they are seeking) rather than a HDD proposal. The idea was that 80% of the benefit would be gained even if only the slow device implemented it. And the proposal allowed a software implementation since people had to have it "immediately." Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 7:20 AM To: [EMAIL PROTECTED] Subject: [t13] optional Overlap obsoletes mandatory Ata op x70 Seek? This message is from the T13 list server. >>> McGrath, Jim 03/20/02 06:55PM >>> Help, I'm lost here, in my stunning ignorance of Ata ... > Later people started using SEEK > as a poor man's attempt to overlap commands Yes. > (since SEEK actually completes immediately, > allowing the ATA bus to be freed for use > by a second drive while the first is still seeking). Ansi T13 never published this fact anywhere, did it? > time to obsolete SEEK (in my opinion) > in favor of the 5 year "new" overlap command > capability that was designed to obsolete it. Do Ata drives actually now commonly implement overlapped commands? Anybody shipping host software to run on the desktop (Apple Mac, Microsoft Windows, Linux) that actually issue overlapped commands to recover Ide bus bandwidth? I hear Atapi devices commonly do Not implement overlapped commands, and that Microsoft Windows includes an remarkably poor implementation for discovering when the bus is again usable. They send a Scsi (aka Atapi) op x2B SeekImmediate before any Read/Write to an Atapi Slave of an Ata Master, no matter if the Ata Master is in use or not. Then they then poll x3F6 AlternateStatus & x11 (DSC|ERR) on a 19.2 Hz clock ... In effect, they add 2/19.2 = 26ms to every Seek. (Unless you install third-party proprietary modifications to Microsoft Windows that fix all this.) Anybody know better? Thanks in advance. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/
