This message is from the T13 list server.
Pat, I'm still having a hard time figuring out what problem you are targeting. Maxtor has been shipping 1394 personal storage products for over a year now which have a 1394 to ATA ridge in the box, using UDMA - it is not an issue. Similarly, we are shipping USB-2 products today (although that just started). I actually was involved in the design of some bridge products, so I know there are no protocol issues. I realize that people shipping earlier parallel port and USB 1.1 products did not use UDMA, but that was because they did not need the speed. When you need it, you can ship with it. Also, none of this has anything to do with Wintel. Apple uses UDMA find on their systems, and do many UNIX boxes. I've never heard of a problem with the UDMA protocol (other complaints about ATA, but not UDMA per se). In particular, I cann't make much sense out of your example. Yes, the bridge chips need to address issues relating to transfer lengths. But like a miniture host, they have all of the same knowledge and capabilities the a host has in working with a device. In practice they have smaller buffers, but that makes little difference as long as the PC to bridge connection is slower than the bridge to device. My experience is that when the host has to shut down the transfer to/from the PC the problems are primarily due to the rather high overhead (by UDMA standards) or restarting that transfer again at the PC level. It's not uncommon for people to get into trouble with buffers that are too small, but that is hardly a protocol problem (especially since the buffers you need are well withing the capabilities of any CMOS ASIC today). All this is not to say that a good bridge design is trivial (it isn't). Just that I don't see how UDMA vs PIO is an issue. Jim -----Original Message----- From: Pat LaVarre To: [EMAIL PROTECTED] Sent: 12/2/01 7:49 AM Subject: [t13] UDma count well not - 3 of 4 - real examples This message is from the T13 list server. [Voici the third 4KiB of, whoops, sorry, more like 16KiB.] > ... H ... D ... In informal talk like this, I speak of these two counts as signed magnitudes: positive means bytes moving out from host to device, negative means bytes moving in from host to device. The generic UsbMass protocol communicates the sign separately from the magnitude: bmCBWFlags.Direction 0/1 = out/in is separate from dCBWDataTransferLength. > measurably real ... millions > ... ordinary people can observe In the design of UsbMass, we could only argue from a knowledge of people: all we could say was that when a host person and a device person independently write code to communicate they are likely to disagree creatively without accurately anticipating the details. Now we know what we then hypothesised is in fact real. Aye, in all normal situations, H = D. Aye, when D and H agree in sign but D < H in magnitude, often the device is polite enough to report an error and then often the host is polite enough to distrust all the data. What demands more thought are the remaining situations. What happens when the plug 'n pray process leaves the host and the device in slight disagreement over which bits meant a byte count in what units? We get H != D despite the device seeing no error! Wanna walk thru some concrete real world use cases? 1) I remember seeing an Apple host combine with a mouse to only occasionally zero the trailing bits of a command on its way to a Usb disk drive. The drive saw a request to read/write zero bytes and completed that request without error. The host only knew trouble was at hand because the Usb1/Pio4 bridge was able to report precisely that zero bytes had moved. Scsi/Atapi quite carefully accept a request to read/write zero bytes as a complex form of no-op. I can't remembr if on paper Ata requires an error in this case? 2) I remember seeing a Linux host think it was asking to move the first two bytes of a header while a device thought it was asking to move the whole header. Irony #1: Me, I agreed with the host, but the firmware for the device shipped as binary code only, in rom. Irony #2: An earlier version of the same host had asked for whole headers ... but choked when a popular Wintel Ide Dma connection was found unable to handle D < H with anything less drastic than a 7.5+/-0.5s timeout. Some other device thought the header only contained 2 bytes whenever the media was absent. I've never seen any protocol but Ata have the sense to demand that all transfers to/from a block device be multiples of blocks. I wonder how many of these subtle horrors arise largely from a widespread and misplaced zeal to save memory. 3) I remember seeing PC app's allocate space only for the max number of bytes that a well-known device actually will move in response to a particular command. Those app's do not make room for extra bytes of UDma garbage. Saying sorry we smashed some extra memory is not an error from which they know how to respond determinately, much less recover. If UDma permits the sender to clock garbage, then even a host that double-buffers its i/o can't know how many bytes to move to/from app space. The garbage reaches all the way back to the app, just like the out-of-band communication that decides which bits of the command mean a count of bytes moving which way in what units. [The last 4KiB of 16KiB (this time I counted more carefully) is soon to follow.] Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
