This message is from the T13 list server.
Don, You can't really completely test ECC today with the limited capabilities of the READ/WRITE long commands. The problem is that only 4 bytes of the much longer ECC field can be modified, so that in essence some of the data (at this level user level and ECC are both "data") simply cannot be modified via the interface. As for Big Blue, the reward they got was quite large for compatibility. This is very high margin territory (i.e. big systems, like mainframes). But ongoing support and testing costs were also high. At the end of the day customers paid enough in higher prices to offset the higher costs and make it worthwhile for IBM. The problem is that none of this is true in the PC industry, and especially for the HDD segment of it. Personally I would like nothing better than to produce non commodity HDDs that offer lots of extra value for the customer and sold for a higher price that both covered my cost and made me a profit. Unfortunately, that's extremely difficult to do today given how the PC and HDD industry have been structured. Jim PS the savings in obsolescing functions over time is to reduce the development and support costs for those features. Every product (we do several a year) requires that we test the features and make any adjustments to make them work. In absolute terms the costs are not huge, but given the financial health of the HDD industry it shows up on our radar. -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 13, 2002 8:17 AM To: ata reflector Subject: Re: RE: [t13] R/W Commands This message is from the T13 list server. This is a reply to Jim McGrath's email which is included below for reference. Even in 1986, SCSI had a significantly smaller market share than the PC, I don't remember the exact numbers. Like I said, ATA devices were mostly 4 bytes until about 1989, 1990. But that doesn't really matter. The real point is that people had figured out how to use R/W Long for *completely* being able to test ECC regardless of how many bytes of ECC there were. And it is still being done. And has also been pointed out, R/W Long is still being used, maybe not by your company or any of the "politically significant" people on the committee, but by several other vendors. Enough so that the command should not have been obsoleted. Please cite what the Big Blue big price for compatibility was. It would've cost significantly more for the companies to replace their software if that compatibility would NOT have been maintained. And the same is true for the PC. Although it IS true that a certain individual has gotten extraordinarily rich by regularly obsoleting his own software. (I wonder if there are any numbers showing how much of Americas GNP has been wasted by this individual in this endeavor.) The hardware and software to implement R/W Long is insignificant compared to the rest of the hardware and software. It can be handled as a special case in the course of normal R/W code and hardware. Providing testability is a necessity in an interface. If you look at the totality of the hardware and software that were included in the orginal interface for testability, it is insignificant compared to the functional hardware and software. There is no valid reason to obsolete much of what has been obsoleted except for NIH, politics, and short sightedness on the part ATA committee. Repeatedly, stuff has been obsoleted over the objections of other companies on the interface. There is also no valid reason why a 1986 model drive should not be able to be plugged on to a cable with a 2002 model drive and be able to boot and work. 3/12/02 6:52:31 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >This message is from the T13 list server. > > > >Don, > >In 1986 I worked on our Q200 product, with used a 96 bit Reed-Solomon ECC >code. It was a high volume product (it was sold to Apple for the Mac among >others). Once again, this was made possible by embedding the controller into >the HDD. > >My mental database does not go back that far for competitor drives, but I'm >sure they were, well, competitive :-). If you can cite differently please >do. > >As to IDE (actually, ATA - that the standard, you are probably thinking of >the "vendor unique" interface I mentioned), I know exactly when it started >since I actually started it (well, along with Dal Allen). The intent was >actually to standardize what was then known as the "Conner compatible" >interface, based on the earlier vendor unique work done by a multiple of >folks at IBM, CDC, WD, and Compaq. We did not complete ATA-1 until 1990 >(you can still get a copy off of the T13 web site). > >At the time we did not even think much about this issue - the merging of >drive and controller was still fresh in people's mind, and eliminating these >commands would have been a bit premature. After that inertia took over. >T13 really did not get into the habit of obsolescing things for quite some >time. Note that ATA-1 and ATA-2 themselves are now obsolete (i.e. withdrawn >standards). > >I don't dispute that vendor unique commands to test a lot of things work - >we have commands that bypass defect management, allow you to create and >erase servo bursts, etc... But they are not made available to customers and >so the ATA READ/WRITE LONG commands have nothing to do with that. > >On correction spans, you have not been able to test the correction ability >of the ECC for at least 10 years. Once you are restricted to just modifying >a subset of the ECC field (and not even a well documented specific subset) >there are just some testing you cannot perform. > >Partially testing a drive vendors ECC is sort of silly, since we completely >test it (using vendor specific commands). Indeed, while customers were >initially nervous when we started doing ECC on drives (afterall, we had not >done it before), by 1990 I don't know of a single customer who thought that >was a big issue (at least with our drives). Today some of the best ECC >people in the world work at disk drive companies - testing our ECC is sort >of like testing PW50. Customers who understand these issues make sure we >run the appropriate tests - they don't rely on their own testing to verify >things at this level (they may do that sort of testing, but they don't rely >on it). BTW, the ECC on a drive is being constantly employed for both >detection and correction. It's not like it's some idle circuitry you have >to exercise. > >As for Big Blue, you forget to mention that that software compatibility of >30 years comes as a big price. And Intel was trying to protect the >investment in an applications software base of over 10,000 programs, and >were rewarded quite well for that. If people are willing to pay for that >degree of compatibility, the market will provide. Conversely, if they are >not providing it, then the market is simply not willing to pay for it. > >Jim > > > > > > >-----Original Message----- >From: don clay [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, March 12, 2002 2:42 PM >To: ata reflector >Subject: [t13] R/W Commands > > >This message is from the T13 list server. > > >The following statements are NOT true. > >1. I think you're missing the point. For more than a decade ECC fields >have >been longer than 4 bytes. Basically the READ/WRITE LONG commands have >not been valid for their original purpose for at least that long, probably >longer. Indeed, I don't think they have been valid since drive >manufacturers began integrating the controller onto the drive (i.e. the >entire lifetime of the ATA standard, going back to ATA 1). > >Note - ECC lengths of greater than 4 bytes were not prevalent until quite >some >time (3 or 4 years minimum) after the IDE came into existance. > >2. Remember that ATA was a standardization of what was originally a vendor >unique interface developed in the days when controller boards and HDDs were >separate devices (i.e. the early 80's). At that time such a function make >sense. When the two were combined, this original purpose lost its meaning. > >Note - Testing of correction spans and limits continued way beyond this >point. >Additionally, with the use of vendor unique commands, ECC testing has >remained valid. > >3. Actually, all HDD ECCs are vendor unique - their length is not standard, >and >going forward it's not even clear that ECC will be linked with 512 byte >sectors. And unless you know the codes being used, trying to test it is >pretty useless (the drive itself, and certainly the manufacturing process, >does a better job). > >Note- Again with vendor unique commands, ECC testing remains valid. No one >has time in the manufacturing process to do anything more than verify basic >funcrtionality of ECC. > >Furthermore the following statement is easily disputable with the following >two >examples. If Intel had taken the approach of the ATA committee, software >would have become obsolete with each new generation of processor. If IBM >had taken this approach, the big box would not still be alive after 30 years >as >their software would have been repeatedly obsoleted. It is only the NIH, >politics, >and short sightedness of the ATA committee that has prevented a drive that >ran >in 1990 or EVEN from 1986 from being able to be put on a 2002 PC. > >If anything, the ATA committee is way too slow in obsoleting functions! > > > >
