This message is from the T13 list server.


Don,

Ah, the SEEK command.  SEEK was NEVER used in ATA for READ/WRITE - from day
1 (i.e. ATA-1) we had the READ/WRITE commands.  SEEK is actually a holdover
from pre ATA days - namely the old WD1003 controller using drives attached
via the ST406/512 interface.  That operated by having the controller
instruct the drive to SEEK to a cylinder, and then just turning on/of the
read/write electronics (which were on the controller, not in the drive) at
the right point in time.

Seagate was the biggest producer of these drives.  The largest MFM/RLL drive
they ever produced was the ST1106R, a 128 MB drive.  After that the desktop
transitioned to embedded controllers.  I don't know of many people even
using that drive today, and if they wanted to upgrade to a new ATA drive
they would encounter a lot more problems than the potential lack of a SEEK
command.

BTW there was lots of capabilities that were initially carried over from
ST506/412 that we lost over the years.  I have not heard anyone argue to
bring back the RECALIBRATE command for instance.

Later people started using SEEK as a poor man's attempt to overlap commands
(since SEEK actually completes immediately, allowing the ATA bus to be freed
for use by a second drive while the first is still seeking).  But this was
recognized by everyone as being inadequate, and so the overlapped command
capability was introduced - first in ATAPI, then merged into ATA in ATA-4.
After more than 5 years of using overlapped command and command queuing, its
time to obsolete SEEK (in my opinion) in favor of the 5 year "new" overlap
command capability that was designed to obsolete it.

Jim


-----Original Message-----
From: don clay [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 2:28 PM
To: ata reflector
Subject: Re: [t13] Re: ^ 18 R/W Long commands


This message is from the T13 list server.


In a previous email on this thread, i described how it is possible to make
R/W 
long capable of completely testing ECC.  The ways to provide access for
testing 
are only limited by one's imagination and that includes on the interface.
Cheap 
to do as well.

Anybody who's going to buy a godzillion drives from a company has a few
rights 
to verify that what they're buying works without a "mistrust" guilt trip
being laid 
on them.

Of course, most OEM's would rather have the drive manufacturer's test the 
drives for them, but often times they provide the software which, in some
cases, 
uses R/W Long.

But the big picture point is that these commands should not be obsoleted 
without a public forum on this reflector prior to their elimination.
Furthermore, 
unless there is a valid reason (and I haven't heard one yet on this
reflector) to 
eliminate them, they should never be eliminated, obsoleted, or otherwise 
disposed or dropped.

That brings to mind the seek command.  It seems to me that if the seek 
command is eliminated, that people with old machines without Windows will
not 
be able to replace their hard drive.  There is a reason not to obsolete the
seek 
command.

3/20/02 2:48:22 PM, "Hale Landis" <[EMAIL PROTECTED]> wrote:

>This message is from the T13 list server.
>
>
>On Wed, 20 Mar 2002 09:56:59 -0800, Thomas Colligan wrote:
>>This message is from the T13 list server.
>>So why the two positions?
>
>With respect to R/W Long there are two positions: a) the old R/W Long
>commands are inadequate to test a modern drive's ECC -and- b) due to
>a lot of "mistrust" many disk drive customers feel a need to perform
>this testing. OK, if a disk drive manufacturer wants this business
>then that manufacturer will implement a set of vendor specific
>commands to test the ECC of their drive (or even specific model of
>drive). Those vendor specific commands might even "look like" the old
>R/W Long commands. But in general we have progressed past the days
>when commands like those intended to test MFM disk controllers are
>adequate. And testing the ECC on modern drive model A may be very
>different than testing the ECC on modern drive model B.
>
>>Everyone, happy except for drive suppliers because they would have to do
as
>>their customers ask. What a novel Idea?
>
>But when customer ask for things that make no sense what should T13
>do? The answer is T13 will wait for someone to bring in a proposal
>that makes sense. I don't recall a single proposal in the last 4
>years to define a new and better way to do ECC testing from a host.
>
>>As Harlan stated it is getting harder and harder to test today's ATA hard
>>drives for a number of reasons. I expect HDD supplier factories are under
>>the same constraints. How do you completely test a 120GB in the time
>>required by upper management,  and state that the drive is good. We should
>>be adding new test technologies that allow for a quicker analysis of drive
>>issues. As the capacity of today's HDD increase the more difficult it will
>>be for all of us. 
>
>What do you want to test? Many drives have all their hardware logic
>and firmware inside a single chip. There isn't much that can be
>tested externally with any real confidence. Only the drive can test
>itself internally and report the result (isn't that what SMART is all
>about?). But I hope everyone knows that a modern disk drive runs a
>multitasking "OS" with anything from four to eight tasks, each
>responsible for some part of the disk drive's operation. How are you
>going to test that? But I'll ask again... What parts of a disk drive
>do you want to test (and why)? Lets see the proposal(s).
>
>
>
>*** Hale Landis *** www.ata-atapi.com ***
>
>
>
>


Reply via email to