This message is from the T13 list server.
[Ouch, looks here like the mail agent here quietly discards anything beyond the first 4KiB of an email. Here, retransmitted, is the middle 4KiB of 12 or so.] > I don't know of DMA systems > where you don't program byte counts! Good to hear, thank you. Me neither. All the more ironic that SwDma/MwDma/UDma all share the defect of neglecting to provide the Dma engine with a way to convey this signed byte count to the device so that someone on earth could see both the host count and the device count simultaneously. Core FireWire & Usb fix this. There, every core communication - standard or vendor-specific - shares a common scheme for transmitting to the device the sign and magnitude of the byte count the host is expecting to move. (I regret to report the layers above vary in how well they preserve this quality. The generic flavour ofUsbMass (bInterfaceProtocol = x50) does.) > > UDma > protocol does work in practice, does it not? To read/write a hard drive from a Wintel motherboard? Yea, it works great. Ata UDma block read and block write work well enough any time out-of-band communication correctly decides the direction and the byte size of data transfer involved. And they work great any time no media trouble is involved. Because Ide connections are so common, I count myself among the people who would like to see Ide connect together well more things than Wintel and a hard drive. Just this moment, I'm trying to get informed enough to guess what practice will be like when people ship millions of FireWire/UDma and Usb2/UDma bridges at commodity prices. (As best as I know, as yet, these bridges have not yet become commodities - if you know different, please tell me!) > The concern over too many bytes is ill founded. A piece of this problem is old, aye. I think I'm hearing that UDm by design first makes this problem matter and then, helpfully, makes this problem worse. Fundamentally, UDma shares the limitation of SwDma/MwDma - and of Pio as implemented in Win95B - of being unable to distinguish between N bytes and (N - 1) bytes transferred, for N a positive multiple of two. In the past, people could use Pio in place of SwDma/MwDma, merely by providing a Pio accelerator to make Pio run as parallel and thus as fast as Dma. But now we (T13) have capped Pio bursts down below 17MB/s while advancing UDma to 33, 66, 100, and beyond. As time marches on, more and more Ide connections which were using Pio will now have to change to use Dma, warts and all. I know of shipping host code that works today only by arranging for nothing but block read/write to involve Dma. Because this code constructs its own commands, it can know which are block read/write and which just coincidentally move a multiple of blocks. Now with UDma we have an Ide Dma we can't replace with a Pio that works. Ouch. > The concern over too many bytes is ill founded. This problem is now measurably real. Generic UsbMass bridges from Usb1 to Ata/Atapi Pio4, shipping in the millions, carefully compare how many bytes the host thinks will move which way, H, to how many bytes the device actually tries to move which way D. These bridges have to compare D and H, because the UsbMass protocol requires a Usb STALL any time D != H (to attain the max-theoretical 1216 bytes/ms of Usb1 while yet still ducking nasty core Usb issues that otherwise arise). Not only can a bus analyser easily trigger on a STALL, but the STALL recovery of enough hosts is slow enough that when STALLs are frequent, bus bandwidth takes a hit, and ordinary people can observe, for example, that they just created a coaster when they meant to burn a CD. [The last 4KiB is soon to follow.] Subscribe/Unsubscribe instructions can be found at www.t13.org.
