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