This message is from the T13 list server.
Don, So are we agreeing that this level of testing (ECC) is the responsibility of the drive manufacturer (in their "test and manufacturing process") and not the customer? In that case you don't need a standard READ/WRITE LONG command set. We do a lot of testing of drives in both development and manufacturing, doing things that a customer would never do on their own drive, mainly with vendor unique commands. I'm sure other manufacturers do similar things. But ATA is not meant to be a standard for the drive manufacturing process, but for end user use. And for them using the old READ/WRITE LONG for ECC testing makes no sense. BTW, I actually like the idea of a capability to allow the drive to test the HOST system by injecting errors into the returned stream. It's similar to what we do by forcing errors in drive components. Given the software intense environment today, testing those error paths in the driver stacks makes a lot of sense to me. Jim -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 12, 2002 3:57 PM To: ata reflector Subject: Re: RE: [t13] future of R/W long This message is from the T13 list server. ECC testing is often done by testing on multiple PC's over long periods of time and then a shorter test is implemented for manufacturing. It is also tested by hardware simulations and other software techniques during ASIC development. The same is done for memory and microprocessor testing. Then, both of these are usually tested in board test in the manufacturing process. Hosts don't often test drives anymore. Instead the qualify the disk vendor's test and manufacturing process. Bottom line, there is no double standard. 3/12/02 4:23:56 PM, "Hale Landis" <[EMAIL PROTECTED]> wrote: >This message is from the T13 list server. > > >On Tue, 12 Mar 2002 13:54:13 -0800, McGrath, Jim wrote: >>This message is from the T13 list server. >> >>going forward it's not even clear that ECC will be linked with 512 byte >>sectors. > >When I make my first "large physical sector" proposal I asked the T13 >members to think about this and how they would continue to support >R/W Long testing. > >Lets assume the current R/W Long scheme (Harlan's implementation or >something similar) is used but the sectors are 4K bytes and there are >up to 500 bytes of ECC data. Anyone want to estimate how long it >would take just to walk a single "bad bit" though such a sector+ECC. >Then how about walking a 2 "bad bits"? Or combinations of multiple >errors? I'm not sure any of us would live long enough to see such a >test complete (even if you could find a computer system that could >run that long!). > >A question for those of you that buy disk drives... When you purchase >a disk drive don't you assume that someone has verified that the >drive's microprocessor(s) and buffer memory function correctly? >(There has never been a way to test a microprocessor in a drive from >a host system.) If you need to test a drive's ECC logic from the >host, then why don't you also need to test the drive's microprocessor >and buffer memory too from a host? Why the "double standard"? > > > >*** Hale Landis *** www.ata-atapi.com *** > > > >
