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! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
