This message is from the T13 list server.
Don, First, not all opinions are equal. I've worked at a disk drive company for 15 years, and I know whereof I speak. Perhaps more importantly, a lot of folks on T13 are equally well educated on these sorts of issues. You keep on asserting no there are costs, despite the facts that they're been outlined to you. You are just not listening - so I'll stop talking. Second, the burden of proof is always on people advocating change - in this case to add READ/WRITE LONG back into the standard. My (constructive) suggestion has been to put together a proposal that accomplishes what people want (whether that's really testing ECC, error injection, marking sectors, etc...) and submit it to T13. Or even wait until it is published and offer a public comment. If you are not willing to make the effort, then it's obviously not a very important topic for you. Jim -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 9:16 PM To: ata reflector Subject: [t13] Re^16 R/W (Long) Commands This message is from the T13 list server. The costs to test the R/W long command are next to zero, as in unmeasureable, as is the cost of the hardware to implement it. You need to attempt to find a different point on which to hang your hat. And actually, there is not one available for you. 3/18/02 9:23:11 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > >Don, > >"In initial debug there might be some issues (again of insignificant nature >compared to getting R/W and the rest of the drive working), but by the time >a >drive goes into manufacturing, they will be resolved." > >You are sort of getting the point, but missing the message. ANY costs are >an issue today. Costs are often viewed as opportunity costs. i.e. not so >much how much wages do I pay people, but rather how long this could delay a >product and/or other developments for which (paying) markets have been >identified. As a simple example, a day late for us is over $1M short. >Given that, engineers quite properly push back on any additional work >required that could increase development time or even the risk of an >increase in development time. > >Rather than dismissing the costs, which I don't think is a very convincing >argument (especially to those incurring the costs), perhaps a better tack is >to promote a proposal that has the potential to add revenue (via prcing or >market size). Unfortunately, that's pretty hard given the state of the >industry, but I think it has a better chance of persuading people. Indeed, >past proposals that T13 has adopted generally have that in common (even then >people are cautious about incurring costs). > >Jim > > >-----Original Message----- >From: don clay [mailto:[EMAIL PROTECTED]] >Sent: Monday, March 18, 2002 5:53 PM >To: McGrath, Jim >Subject: Re: RE: RE: [t13] Re: RE: Re^10 R/W (Long) Commands > > >The R/W Long command has a low probability of changing from drive to drive, >expecially on the testing side. On the drive side, it should be independent >of >addressing in that it should use the drives common address handling >routines. >In initial debug there might be some issues (again of insignificant nature >compared to getting R/W and the rest of the drive working), but by the time >a >drive goes into manufacturing, they will be resolved. > >As I've indicated previously, the standards committee should have enough a >broad enough perspective to poll users of the standard so that it >understands >what ALL users of the standard are doing before it makes a decision to >obsolete hardware and commands. Not everyone who is using the standard >should have to come to every meeting out of self-defense. > >Your example of converting to XP is not a relevant example. Microsoft >continually makes changes that break current software. That's why software >vendors list which of Microsoft's OS's on which their software will run. >Microsoft >even has a program for the older versions of their OS that will tell you >what >software and hardware will or will not run under XP. To convert to XP can >be a >very expensive proposition for people who have a lot of programs on there >computer. > >Furthermore, Microsoft has regularly changed file formats for even their own > >programs which force people to buy the latest and greatest versions of their > >software. > >Other industries have been very successful in accomodating backward >compatibility. Sometimes, they even make it work for decades or centuries. > >Imagine that! > >3/18/02 6:13:20 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > >> >>Don, >> >>The problem is not the testing it is the extension or what happens if the >>testing fails (i.e. what do you do)? Given the changes to ATA addressing, >>it's quite possible that people felt that in order to continue to make the >>function useful you would end up either extending it and/or fixing it (or >>explaining to customers why their old READ/WRITE LONG no longer works on >>part of the disk drive). >> >>Once again, I'm not privy to the details on this issue in T13, but I >suspect >>that the address change and the obsolescing of these commands were not >just >>coincidences in time. >> >>Finally, you appear to believe that code, once written, will always work. >>Since we tend to change the hardware that the code runs on every product >>(and a lot of the other code that runs along with it), that's just not true >>(we even change microprocessors and languages used to implement the >software >>on occasion!). >> >>To put it in a more familiar context, a lot of things that use to work fine >>on older PCs running older OSes fail on newer PCs with newer OSes. I just >>installed Windows XP at home and had a really good time cleaning up >>applications that ran fine on Windows 98 and no longer run on XP. And this >>is a market where Microsoft is being paid quite a bit of money to make >every >>attempt to preserve backward compatibility. >> >>So over time there is an excellent case to be made to obsolete some things >>in the interests of making other things easier/cheaper to do - industries >do >>it all of the time. Making that call at a particular point in time is up >to >>the suppliers of course - all obsolescing it in the standard does is to >>allow them over time to make those decisions and still remain compliant >with >>the standard. >> >>Jim >> >>PS the T13 committee is an open standards body, with modest fee >requirements >>(I think it may be $500 to $1000 total a year). Not only companies belong, >>but so do some individuals (usually as consultants in the industry). If >you >>are interested in joining just go to the web site. I've suggested several >>times that people put together a proposal (all proposals are also on the >web >>site) to address any specific issue they want to see addressed. Just >asking >>the committee to reverse itself is, I think, a strategy with a low >>probability of success (since the decisions taken are typically not by >whim, >>but had some reasons behind them). >> >>-----Original Message----- >>From: don clay [mailto:[EMAIL PROTECTED]] >>Sent: Monday, March 18, 2002 4:33 PM >>To: McGrath, Jim >>Subject: Re: RE: [t13] Re: RE: Re^10 R/W (Long) Commands >> >> >>Of course firmware testing is not trivial. However, some parts of the >>testing is >>trivial compared to other parts. Verifying correct operation of the R/W >>Long >>commands is trivial compared to data integrity testing or testing the >>Security >>commands or testing the power commands or testing other specifics of the >>standard. Changing the testing of this command from product to product >>requires NO changes to tests.The amount of time that goes into testing the >>R/W Long command is insignificant monetarily and as a percentage of the >>total >>time used to verify the rest of the drive is functioning properly. The >>amount of >>hardware to support R/W Long is orders of magnitude less than the total of >>the >>drive. >> >>Orders of magnitude more time is wasted waiting for the Host to acknowledge > >>interrupts than is used to test the R/W Long command. Orders of magnitude >>more time is wasted on interrupt latency that is wasted testing the R/W >Long >> >>command. >> >>Removing firmware commands and hardware requires changes to these >>formware tests used to verify correct operation of the drive. That does >>cost >>money. >> >>Obsoleting commands that are used by companies that are using this >standard >>exposes those companies who are using the obsoleted technology to the >>further whims of this committee. >> >>I entered the thread with the point that obsoleting functions that were >>currently >>in use is wrong. It is so because BACKWARD COMPATIBILITY IS >>IMPORTANT. It is so because people are using the R/W Long command. >> >>NOT LISTENING TO THE WHOLE OF THE PEOPLE ON THE BUS IS ALSO >>WRONG. THOSE WITH NARROW PERSPECTIVES SHOULD NOT BE ON >>THIS COMMITTEE. A STANDARD NEEDS TO ADDRESS THE >>PERSPECTIVE OF ALL THE USERS OF THE STANDARD AND NOT >>INDIVIDUAL SELFISH INTERESTS. >> >>3/18/02 3:55:25 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >> >>>This message is from the T13 list server. >>> >>> >>> >>>Don, >>> >>>Firmware testing is not trivial. It can involve hundreds of systems >>running >>>for several weeks in an overworked compatibility lab. >>> >>>As long as the function in question was not changed (e.g. not updated for >>>the new addressing system) or causes testing problems, these costs were >>>folded into general firmware testing costs. But remember that this whole >>>thread began with people discussing the extension of these commands to >the >>>new addressing system, which by definition is work and new testing. >>Indeed, >>>the new addressing extensions probably raised this whole issue originally >>(I >>>may be wrong - READ/WRITE LONG has had many detractors over the >years >>- but >>>it would have prompted my concern). >>> >>>Remember that many of the uses (like marking a sector for later processing >>>by the OS) do require the address extension. Probably most manufacturers >>>will continue to leave the command in there as is with no changes. All >>>obsolete means is that if extensions are desired or the function creates >>>bugs, then the supplier has the option of not doing the work required and >>>still remain ATA compliant. >>> >>>Jim >>> >>>PS Don, in general you should not be forwarding private communications to >>>the reflector. I'm a nice guy :-) , but a lot of others would take >>>substantial offense. >>> >>> >>>-----Original Message----- >>>From: don clay [mailto:[EMAIL PROTECTED]] >>>Sent: Monday, March 18, 2002 2:07 PM >>>To: ata reflector >>>Subject: [t13] Re: RE: Re^10 R/W (Long) Commands >>> >>> >>>This message is from the T13 list server. >>> >>> >>>Again, you are presenting arguments against testing of functions that are >a >> >>>miniscule amount of testing, as in INSIGNIFICANT. >>> >>>You have probably spent more engineering dollars on your replies to these >>>emails than would be spent over the lifetime of testing these functions >>that >>>you >>>have obsoleted. And these are functions that you have now admitted that >>some >>> >>>companies still use. >>> >>>Furthermore, other companies have said repeatedly that they still use >them. >>> >>> >>>3/18/02 2:02:28 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >>> >>>> >>>>Don, >>>> >>>>The problem is that today HDDs are increasingly viewed as a commodity, >>with >>>>no need for testability. Of course some customers still want that >>>>capability, but they are typically the larger OEMs (since they have the >>>>resources to do the testing and have a lot to lose if a bad product >>escapes >>>>from them, so can afford the infrastructure required). Even there, we do >>a >>>>lot of the testing that the OEMs use to do directly. >>>> >>>>Smaller customers typically buy through distribution. Indeed, drive >>>>suppliers often don't even know who these customers are (distributors do >>>not >>>>tell us). Selling products through distribution has always been a less >>>>technical sell than with OEMs, instead relying on basics like price and >>>>promotions. >>>> >>>>The bottom line is that an abstract market pull has no effect on >suppliers >>>>if it is not economically visible to the suppliers. If a supplier is not >>>>rewarded for the work, but rather someone else in the distribution chain >>>(or >>>>just the end consumer) captures the reward, then there is no incentative >>to >>>>do the work. BTW, this is a real common problem with "commodity" >>products. >>>>Everyone likes the low prices, intense competition, and standardization, >>>but >>>>they wonder why suppliers don't innovate except along the lines that they >>>>will be compensated for (like higher drive capacity in the case of HDDs). >>>> >>>>On the work involved, the dominant work involving software is testing. >>>This >>>>is true for new code, and especially true for old code. Whether the code >>>>works or not, every time we change anything in software we have to re >test >>>>it. And that costs time and manpower. Money is saved by reducing these >>>>tests costs. Indeed, money is saved for customers as well, since if they >>>>are doing testing they have to test less also. >>>> >>>>Over time commodity products reduce the number of features they offer >>(from >>>>the earlier, non-commodity days) and instead focus on the "core" values >of >>>>the product. By its nature the opposite - product differentiation - >>occurs >>>>when things get non commoditized, and suppliers can target specific >market >>>>niches and earn better returns by focusing product features to work well >>in >>>>those markets. Today the HDD market is in a fairly heavy commoditization >>>>mode, not a product differentiation mode. I personally don't like that, >>>but >>>>I realize it. >>>> >>>>Unfortunately the thing that has been driving any investment in novel >>>things >>>>in HDDs - the prospect of expanding the market - is also not in good >>shape. >>>>We have a whole division set up to do HDDs for CE applications, and >>another >>>>for Network Storage Applications. Neither has been as successful as >>>>originally projected (e.g. PVRs still only sell in the hundreds of >>>thousands >>>>of units per year). And the core PC and server markets have actually >been >>>>declining. And the causes for all of this are not things we in the HDD >>>>group can directly influence (like overall IT spending levels). >>>> >>>>Jim >>>> >>>>PS as to members of T13, you have to ask them what they do and why - I'm >>>>sure there are differences among the members. But since they all live in >>>>the same economic sector, all of this sort of stuff drives their >>businesses >>>>to some degree. >>>> >>>> >>>>-----Original Message----- >>>>From: don clay [mailto:[EMAIL PROTECTED]] >>>>Sent: Saturday, March 16, 2002 6:40 AM >>>>To: McGrath, Jim >>>>Subject: Re^10 R/W (Long) Commands >>>> >>>> >>>>If the ATA committee had even approached the idealism that you espouse >in >>>>this last email, I wouldn't be contributing to this thread. >>Unfortunately, >>>>it doesn't. >>>>Nor is it close. Except in the minds of the politically dominate >>>>individuals (*NOT* >>>>companies) on this committee. If you want examples of this, go re-read >>>>emails >>>>posted to this Reflector... other than mine. >>>> >>>>Secondly, testibility and marketability do contribute to the bottom >line. >>>>And >>>>they are accomodated in the design. And a great deal of time and effort >>>>does >>>>go into them in the design of the product. And providing customers >access >>>>to >>>>testability is a marketing issue, as is backward compatibility. >>>> >>>>Thirdly, a lot of the stuff that would allow backward compatibility that >>>has >>>>been >>>>eliminated from the ATA specification is considerably less than 1% of >>>either >>>>the >>>>silicon and the software of a HDD. SRAM & ROM costs are often irrevelant >>>in >>>> >>>>these days. For example a 2MB ROM might be considerably less cost than >a >>>>1MB ROM if the 2MB ROM has higher volumes. So it is virtually impossible >>>to >>>> >>>>make generalizations about these things. And software costs are often >>>times >>>> >>>>negligible for such things R/W Long. Often times code that is written >>once >>> >>>>carries over for several generations of drives without re-write. >>>Especially >>>>non- >>>>performing commands such as R/W Long >>>> >>>>Fourthly, Innovation really has nothing to do with this thread. I was >>>>merely >>>>pointing out how the ECC command was (and still is being used according >to >> >>>>early contributors to this thread) capable of "completely" testing the >ECC >> >>>>capability and how the R/W Long command can be used with negligible >>>>hardware and software costs. >>>> >>>>3/14/02 12:18:22 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: >>>> >>>>> >>>>>Don, >>>>> >>>>>Companies are focused on profits since that is the function. Other >types >>>>of >>>>>organizations (schools, government, churches) rightly deal with other >>>>>aspects of life. And T13's members are companies, not individuals. >"I'm >>>>>shocked, truly shocked" that a company might be concerned about profits >>>>:-). >>>>> >>>>>Doing the work you describe does cost a company money (e.g. skilled >>>>>engineering labor), and it does show up on the radar map. I know, since >>>>I'm >>>>>been involved in way too many of those conversations internally. >>>>> >>>>>Once again, the problem is that designing something in the standards >>>>>committee reduces the ability of anyone to make a profit, and so reduces >>>>the >>>>>incentative for companies to make the required investments. The >original >>>>>intent of the ATA standard in particular was to document what had >already >>>>>been in existence. It was not originally intended to drive innovation. >>>>>That does not stop people from trying to innovate in the standards >>>>>committee, but its not the optimum mechanism to employ for innovation. >>>>> >>>>>Note that many folks involved in other standards bodies (like IEEE) >don't >>>>>understand some of this since they operate quite differently. IEEE >>>members >>>>>are individuals, not companies. The usual tradeoff is that the "ANSI >>>>>standards" get a lot of industry support, since they are driven by >>>>>companies. A number of standards developed without that sort of support >>>>>never get good industry adoption - but they often have more intellectual >>>>>innovation. >>>>> >>>>>Jim >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: don clay [mailto:[EMAIL PROTECTED]] >>>>>Sent: Thursday, March 14, 2002 8:12 AM >>>>>To: ata reflector >>>>>Subject: Re: RE: RE: [t13] R/W Commands >>>>> >>>>> >>>>>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! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
