This message is from the T13 list server.
> On Thu, 9 Jan 2003 14:33:00 -0700, Pat LaVarre wrote: > This message is from the T13 list server. > 1) Why more people don't appreciate that classic asynchronous & > synchronous 8-bit SCSI and 16-bit ATAPI PIO empower the host to > do a better job of counting data bytes copied than does ATA/PI > DMA. Because in the ATA/ATAPI world there is no such thing as an unknown data length transfer. Every command that performs data transfer has a know number of data bytes. And since the ATA interface is 16-bit the last byte may be a pad byte. When the host decides to issue a data transfer command to a device the host knows exactly how much data will be transferred. Yes, there is the ATAPI "read CDB" issue that some SCSI commands can transfer a variable amount of data but this is always resolved by using the host's Allocation Length value and looking at the data received (for example, looking at the header data from a command like Mode Sense). And everything I said in this paragraph applies to both PIO and DMA - PIO and DMA data transfers are the same. Since PIO and DMA are the same there really isn't any problem for people to appreciate. > 2) Why ATA/PI DMA folk don't want to work to recover what we had > in ATA/PI PIO. But nothing was lost - there is nothing to recover. > 3) Why the Apple/ Microsoft/ Linux host folk aren't pushing the > motherboard & PCI card & device folk hard for better byte > counting support. (My employer - a device maker, may she forever > be anonymous - solved this last year on a vendor-specific basis.) I would like to see this too, but not because I think there is any byte counting problem to be solved, but because I would like to have the options (in a device driver) of doing reliable I/O. But my concept of reliable I/O goes well beyond just counting bytes on the ATA interface. There really isn't much point in fixing the ATA interface unless something is done about the PCI bus that is used on most systems. > 4) Windows grows progressively worse at passing thru such > commands as -x "12 0 0 0 05 0" -i 5 i.e. an op x12 Inquiry for > the data just up to and including the additionalLength at offset > 4. Clearly a bug in Windows device drivers - not any problem with the ATA/ATAPI interface. I see two soltions: Microsoft fixes the device driver bug -or- maybe just just say they don't support odd length Allocation Lengths. > 5) Hale is here, Jim is at least as nearby as T10. Whatever > conversation we had going offline re countable data bytes died > away, leaving me with no memory but a remarkably persistent > failure to communicate. I think we were asked to take the conversation "offline". You sent out a table of host/device expect data transfer lengths and I corrected the table for ATA/ATAPI. That correction showed that all the cases you were concerned about were illegal - they are the result of a host doing invalid DMA operations on the ATA interface. But I think this all started over some X-to-ATAPI bridge device design (USB-to-ATAPI?). I think someone was trying to build a USB-to-ATAPI bridge that could not do ATA/ATAPI DMA correctly because it would break the ATA/ATAPI DMA rules. I think the bridge designer wanted the DMA burst boundaries to be at the media block boundaries (not possible) and no pad bytes (not possible)... but most of all I think the bridge chip designer did not want to decode and understand the ATA or ATAPI PACKET command that was being executed and/or do the kind of data buffering and reblocking (for the ATA/ATAPI DMA burst vs. USB packet sizes). Too bad. That bridge chip is an ATA/ATAPI host and it *SHALL* follow the ATA/ATAPI DMA rules and that means it must fully understand what command it is passing on to the ATA/ATAPI device just like any other ATA/ATAPI host does. And it must be prepared to convert ATA/ATAPI DMA bursts (where there is no restrictions on burst size) into USB data packets (where there are restrictions on packet size). > 6) What will happen when the switch to 64-bit hardware makes the > canonical "-x 12 0 0 0 24 0" -i x24 choke as badly as I hear that > first example does in Win 98, Mac OS X, etc. today. Since the ATA/ATPAI interface is 16-bits wide I would expect a host, even a 64-bit host, to still understand that all ATA/ATAPI data transfers are even length -or- odd length plus a pad byte at the hardware level. And I would still expect the device drivers to understand how to use the Allocation Length value and the data header values (just like a correctly designed host does today). > I would myself enjoy a conclusive discussion of how ATA/PI DMA > could & should or should not count bytes more accurately, but > maybe many of us here remember seeing the requests that we limit > the bandwidth of such a discussion. I don't think there is a problem to be solved or fixed. Yes, host controllers that counted the number of words (note: words, NOT bytes!) that were transferred during DMA on the ATA/ATAPI interface would be nice. But PIO and DMA are the same: Every PIO DRQ block transfers only words - because the following is always true numberWords = ( ( DrqByteCount + 1 ) / 2 ) for every PIO DRQ data packet transferred by a command - no different than DMA where only words are transferred by each DMA data burst transferred by a command. > What should that limit be? Maybe one post per author per day? > Maybe less? I wonder what the average is now for countable data > bytes, from the original inconclusive burst thru til now? When > was that burst? Sometime around or after Nov 2001? How emphatic > was the ban on discussion? Censored forever? Or is a year long > enough? Actually, I'm more curious if SATA can do odd length data transfers? Or does SATA also still require a pad byte if the actual data is an odd number of bytes? If SATA is also a "16-bit wide interface" then it changes none of the issues discussed above. Hale *** Hale Landis *** www.ata-atapi.com ***
