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!
