This message is from the T13 list server.
Let's see. If you add a vendor unique command to enable a special, but very simple piece of software, you can make R/W long transfer all the ECC bytes. This requires no additional hardware, but you have to be thinking about it when you design your ASIC. Very simple, very complete, and it works. All I can about the rest of your reply is that it has been my experience that, as in the example above, it is possible to design in to a HDD testibility and flexibility without costing anything that would show up on the radar screen. It has been a shame that the political controllers of this interface have enforced these types of limitations in their big desire to * "FIX" * the interface for the profit of their company or the imagined screws that they are applying to the competition or NIH. This has been in lieu of attempts at understanding what the original designers of the interface had in mind. It has also, at times, neglected to look at the big picture of other devices that might co-exist on this interface, such as CD's or DVD's (or where they are designed). There has been significant innovation on the interface, however, and there has always been room for it. A very great example of which was implemented by your old company, Quantum, with the development of Ultra DMA. The interface could have been evolved with these innovative new ideas without making old drives obsolete. And this would all be water under the bridge if the committee wasn't still doing the same thing. 3/13/02 7:35:02 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >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! >> >> >> >> > > >
