This message is from the T13 list server.
Pat, The problem I have with your suggestions is that it does not improve anything. The standard already clearly (in the UDMA section) tells devices to ignore these bytes. If an implementer ignores that, or fails to implement it correctly, then the odds are he would fail to implement correctly other things as well. Basically you cannot "fix" the fear that people will implement contrary to the standard by changing the standard. Instead you just penalize people who are implementing to the standard, since this change would require an ASIC turn for device manufacturers. If you tried to post the values you suggest via device firmware you would lose any speed advantage of transferring the data faster - at ATA/133 speeds the you transfer 4 Kbytes in 30 us, so any firmware intervention would be horrible. I have never heard of any shipping device failing in this manner (other problems yes, but not this one). So to make the rest of the world go through hoops to "solve" a problem that no one has seen and that probably cannot be solved with a standards change anyway just does not make sense. Bottom line: There are relatively few device vendors (e.g. 8 ATA HDD manufacturers* in the world, and maybe twice as many CD/DVD manufacturers**). So you don't really have a lot of "amateur hour" problems (i.e. no one in garage shops are making ATA devices). Jim * Maxtor, Seagate, IBM, WD, Samsung, Toshiba, Hitachi, Fujitsu are all the ATA HDD vendors ** LG, Mitsumi, Samsung, Pioneer, Panasonic, HP, Sony, Hitachi, Toshiba, NEC, Yamaha, Ricoh, Funai, JVC, and a handful of others make their own mechanisms, but many of the companies buy their ASICs from a few sources (e.g. Oak Technology). -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 5:56 PM To: [EMAIL PROTECTED] Subject: Re: [t13] this UDMA/PIO stuff This message is from the T13 list server. > From: "Mcgrath, Jim" <[EMAIL PROTECTED]> > Date: Monday - January 28, 2002 5:26 PM Thank you for this new nutshell, I feel we continue ever to clue me in, however slowly. > The device is required > to quietly absorb any extra bytes > the host send during a UDMA data out > (that's in the ATA standard). I don't think this is widely appreciated. Inside the device, this turns into FIFOs that are normally empty at Status time occasionally being nonempty. I have a personal history of pain with people assuming of course FIFOs are empty at this time: Ata/pi implementations that too aggressively change to moving status from moving data can cut data short with this kind of assumption. > since no harm was done Maybe. > why would anyone care > about correcting it anyway I'd like to give the device the option of saying specifically how many bytes it chose to quietly copy into the void. I want this particularly for the case of a total byte count of data that is odd, since in that case nonzero residue is unavoidable. But if we're going to solve that with a residue visible on the bus, then I'd like to see us restore the fully arbitrary byte count negotiations of Pio at the same time. All we have to do is to allow permit the reported residual byte count to be as large as X * 2 + 1, where X is the receiver-side halt-the-transfer indeterminacy designed into Atapi UDma. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
