This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/06/01 05:52PM > Making available [non-whole-block residue] > for UDMA would require the same amount of time to market > since you have to alter ASICs > > (i.e. the register cannot be updated by firmware, > otherwise you have to sit around so long > that you might as well have transferred the data > at PIO mode 0 speeds). Eh? Sorry, I don't follow? Not at all???? To my eye, part of what's cool about UDma is that its delightfully high burst rates let me reduce the cost of data transport to near zero. If I hold the necessary streaming rate constant, reducing data time cost to zero lets me increase command/status overhead accordingly, even enough to swallow some of the horror we see on the host side. For example, to sustain 17e+6 bytes/s, maybe I burst at 66e+6 byte/s. I know of a product that made exactly this choice in summer 2001. Bursting at 33e+6 byte/s cut the sustained rate down to 10e+6 byte/s or so. > (i.e. the register cannot be updated by firmware, > otherwise you have to sit around so long So currently and for some time to come I project that Atapi devices generally can afford lots of command/status overhead - indeed, enough to contemplate parsing commands in the bridge rather only in the device. So what. All the same I agree we want to design to minimise necessary command/status overhead. How about we reserve x00:00 to mean zero OR residue not reported. That way, supporting this feature is free for any well-known block op that the hosts that matter use only when the host and the device agree closely enough on block size to round off potential unobserved residues. > (i.e. the register cannot be updated by firmware, > otherwise you have to sit around so long I hear Ata has a tradition of reporting good status at the end of read in hardware. This can make it difficult, for example, for firmware to learn to report that IORDY was ignored by a rude host in the last bytes of the last block of Pio read data. I don't know of any Atapi device that reports good status in hardware ... ... but, then again, I don't know much about Atapi device hardware than the chips that chosen for the firmware I wrote. Am I any clearer than mud yet? How wrong am I? Thanks again in advance. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
