This message is from the T13 list server.
> Sorry. No need to apologise to me at least: I grinned. > I just have to say that this DMA byte count problem > is mostly an ATAPI problem. Aye, Ata stands alone in its deep, but unobvious, wisdom of insisting that all transfers to any block device involve whole blocks. Too bad T13 folk don't take a more active interest in explaining why Ata works better than Scsi. >From time to time, by relating my years of pain, I have persuaded people to arrange >round to transfer sizes for completely new devices up to multiples of 8: the smallest >universal block size our legacy Scsi standard permits. But I've never met anyone I could persuade to round everything up to the next multiple of x200, no matter how hard I try. Something psychological in people makes them think x200 is a large number. Knowing that Atapi folk live as parasites on motherboard connections built for Ata, occasionally I play with the idea of tunnelling less intrusively thru Ata. Like maybe, if a host identified itself by writing a certain pattern of Lba's out past the capacity, then the next write to a particular invalid Lba would carry a command with all the transfer sizes rounded up to a multiple of x200. To move data in would require two commands: a write command to move the command out, then a read command to move the data in. > Maybe it would help if a few more ATAPI device folks > took an active interest in T13 and attended meetings? I'll try to volunteer myself if/when we begin to agree to extend the protocol to report accurate dma residues. Atapi folk live as parasites on motherboard connections built for Ata. They used to stealing bandwidth, not spending money. Especially with new data transfer modes, the Ata folk pay to get everything right before Atapi comes to the scene. Isn't this how life should be? Traditionally, the immune reaction from Ata folk has been weak: "don't slave your cd-rom to your boot drive, use the secondary port instead". I hear the serial Ata proposal include talk of not requiring daisy-chaining like Usb, unlike FireWire. That will push the cost of the hub off into the comparatively low unit volume Atapi market ... which could easily kick those folk exclusively over to the internal FireWire/Usb market. Wouldn't that be nice? > Maybe it would help if a few more ATAPI device folks > took an active interest in T13 and attended meetings? (-: It certainly would help ... ... if more T13 people took an active interest in Usb & FireWire. ... if more host folk took an active interest in device design and vice versa. ... if more storage folk took an active interest in transparent bridge design. Fun to see that UDma Data In reversing the host/device roles of who sends and who receives clocks suddenly builds an appreciation in each for some of the difficulties of the other. > Maybe it would help if a few more ATAPI device folks > took an active interest in T13 and attended meetings? The active interest is key? Wouldn't do us much good to have people attend meetings without working to apply the discussion there to the problems only they face? Atapi people have been shipping solutions that resort to Pio to fix their Dma troubles since the advent of Atapi MwDma? Atapi UDma is different because Atapi UDma bursts faster than Atapi Pio. Few Atapi people care ... as yet. Can you describe to me any kind of Atapi device that needs bursts beyond the 17e+6 byte/s of Pio4? Gauged by the 150e+3 byte/s streaming rate of a 1X CD, that's over 113X. Do you know any comparative interface gurus clued well into AtapiUDma? That the residue is inaccurate by as much as X * 2 + 1 should among their first observations, but noone here seems to have heard that before? Pat LaVarre >>> [EMAIL PROTECTED] 12/07/01 11:28AM >>> This message is from the T13 list server. I just have to say that this DMA byte count problem is mostly an ATAPI problem. Maybe it would help if a few more ATAPI device folks took an active interest in T13 and attended meetings? Especially since it is mostly ATAPI devices that are being attached to systems via strange X-to-ATA/ATAPI bridge devices. Sorry. *** 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.
