This message is from the T13 list server.
Pat, You keep on saying that the "ATAPI residue" is 5 (4+1). If I have been following you correctly, it is not. It is only 1. The "odd byte problem" only occurs at the end of the command, and then only for devices with transfer sizes for the command (not the block or the burst). If this is a problem, the solution I mentioned earlier (send a single bit residue, 0 or 1, at the end of the command) works and imposes minimal cost on everyone. The other 4 bytes are NOT an issue at the end of the command. At that point no matter how lazy the receiver is in initiating a DMA burst termination, the sender simply has no more bytes to send, and so does not do so. The combination of the two is why you have never heard of this as being a practical problem. The "extra 4 bytes" is not a problem at all, and the "odd byte residue" affects so few devices that they probably have developed their own solution (send the odd byte and let the host sort it out from command context; have the bridge not send the byte but parse the command; or just use PIO). Note that UDMA-33 Cd-ROMs have been shipping for some time. I'm not sure about faster modes (I think the usual problem here is that people don't feel the need for the higher speed, coupled to the more expensive 80 conductor cable the higher speeds need). Jim PS the "extra 4 bytes" problem only occurs during the end of DMA bursts (except for the last one), and is easily handled in a design by just keeping the bytes in the FIFO so that when the next UDMA burst starts you forward them and the new bytes to the final destination. Remember that ATA and ATAPI data transfers are single threaded - once they start for a command they cannot finish until all of the data is transferred. SO you need not worry about losing context like you may in SCSI. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 11:14 AM To: [EMAIL PROTECTED] Subject: RE: [t13] a fix for imprecise UDma residue? This message is from the T13 list server. > ... the number of bytes the device actually transferred. > Yes, for fully reliable I/O this value needs to be checked > against what the host adapter or bridge thinks was transferred. Yes. > For ATAPI devices we have a bit of a problem... not enough ... Yes we lack room in the task file for an Atapi device to publish the total byte count it commonly doesn't bother to calculate with its 8-bit microprocessor. This suggests maybe we should decide to publish just the Ide Residue: the most often zero, else most often odd, count of bytes clocked across the bus that the device did not willingly transfer. Even with UDma 133 allowing, is it 5 extra clocks, the worst case Ide Residue is 5 * 2 + 1 = 11 bytes. That fits easily into the x1F5:1F4 AtaCylinder aka AtapiByteCount registers. > ... the number of bytes the device actually transferred. > Yes, for fully reliable I/O this value needs to be checked > against what the host adapter or bridge thinks was transferred. Checking just the residue would make non-block Ide Dma as reliable as Ide Pio - and more reliable when we have the Crc's of Ide UDma. Agreed checking the total would be better ... but as best as we've guessed so far, that's Hard. Pat LaVarre >>> [EMAIL PROTECTED] 12/07/01 11:12AM >>> This message is from the T13 list server. Here are some ways the DMA data transfer count problem can be "fixed"... First it is not important to know how much data the "host side" transferred (fetch or store in memory). The important number is the number of bytes the device actually transferred. Yes, for fully reliable I/O this value needs to be checked against what the host adapter or bridge thinks was transferred. So... For ATA devices implementing 48-bit LBA and for 48-bit LBA R/W commands the device could place its byte count value into the Command Block 48-bit LBA registers at the end of an error free command. Yea, this would probably be a hardware change. Normally there is no data of interest in the Command Block registers at the end of an error free command (the failing LBA is there for a command with an error). For ATAPI devices we have a bit of a problem... There are not enough bits in the ATAPI Command Block register to hold a reasonable total byte count at the end of a PACKET command. The only way I know around this is implement a new ATA non-data command that causes the ATAPI device to put the byte count for the previous PACKET command into the Command Block registers (using SC, SN, CL, CH and the 4 bits in DH, that gives a 36 bit value). Of course this could also be done using an ATA PIO Data In command or even some new PACKET SCSI CDB command (but only if your wanted even worst performance!). *** Hale Landis *** [EMAIL PROTECTED] *** *** Niwot, CO USA *** www.ata-atapi.com *** Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
