This message is from the T13 list server.
The key thing to remember is that UDMA works perfectly find for all Hard disk drives (and their host connections) up to 133 MB/s. For CD-ROM and DVD drives there are shipping products using it up to 33 MB/s (or faster). The "odd byte problem." is very confusing, and not relevant for Mark's question. As you relayed in an earlier email, all the sector sizes he would be considering are multiples of 4 bytes, and this all command transferring sectors are multiples of 4 bytes in transfer length. So odd bytes are not an issue related to sector size. Rather than go down this particular path again in more detail, I'd ask Mark if his question was answered (and if not what additional information he specifically needs to know). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 4:59 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [t13] Question: ATAPI (CDROM) sector size for DMA This message is from the T13 list server. > "Mark Sawyer" <[EMAIL PROTECTED]> 01/24/02 03:13PM > My problem is ... DMA. > In the case of PIO, ... not a problem > since the device tells me how many bytes to expect. ... > "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/24/02 05:36PM > One short response - the UDMA protocol > has nothing to so with sector size. > The two are completely independent. This point, some of us, perhaps with more ignorance and less ownership here than Jim enjoys, have failed to understand. For awhile I thought we all agreed the byte counts for UDma in or out get off by one when the total length that Pio transfers is odd. I gave up talking here when I was corrected on this point, as quoted below. But some of us think in the lab we see the byte counts for UDma Out gets off by more and more as the UDma burst rate increases. To avoid this, to remove the max inaccuracy of 2 * X +1, this minority of folk is foolish enough to believe a block size K has to be agreed which is even and larger. In the example of UDma66 (aka UDma mode 2), X is 2, so K has to be 6 or larger, so you can't support accurately counting the bytes of all the standard SFF8090i block sizes simultaneously (because there the Gcd is 4). Alternatively, in some vague magical way less than all of us understand, the host and the device can perfectly agree out of band precisely how many bytes will move when there is no error reported, and then also agree perfectly out of band to never care how many bytes did move when there is an error reported. Get all this agreement in place, and all the inaccuracy designed into AtapiDma byte counting disappears. Pat LaVarre >>> "Pat LaVarre" <[EMAIL PROTECTED]> 01/03/02 04:07PM >>> ... > > Another byte count that matters > > is the count of bytes actually written or read. > > ... > > iocdb x 12 0 0 0 FF 0 /i x1000 > > > > Now suppose the device under test > > makes x91 bytes of Inquiry data available. > > With an AtapiPio device we see the host copies in x91 bytes. > > With an AtapiDma device we see the host copies in x92 bytes. > "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/03/02 02:04PM > Your latest covers the same ground we have already covered before. > ... this is incorrect. At the ATA interface level > you always see 92 bytes, whether it is PIO or DMA. > It is up to something else on the host If we can't agree something as plainly broken as this is a problem ... ... I give up. Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
