This message is from the T13 list server.
> > the requests that we limit the bandwidth of such > > a discussion. What should that limit be? Maybe > > one post per author per day? For this topic, I'm now going to try living by that rule. Please allow me some days, and several posts, before you conclude I have failed to read and to try to understand every word posted. I'd very much like to see us forego the discussion of whether the world should or shouldn't be this way. I'd like to focus on how T13 can best help us cope, given that the world IS this way. > From: Hale Landis [mailto:[EMAIL PROTECTED]] ... > I think this all started over some X-to-ATAPI > bridge device design (USB-to-ATAPI?). Yes indeed, this topic began to interest me when first I saw that substituting USB for ATAPI can make results differ. But we can have a simpler discussion if we can focus on just when exchanging PIO and DMA breaks ATAPI, without involving ATA and USB. > ... PIO and DMA data transfers are the same ... I'm saying, so long as people can fix things by turning off DMA, then DMA is broken somehow. Either the device DMA is broken, the host DMA is broken, the T13 DMA spec is incomplete, or some combination thereof. T13 has work to do here only if its DMA spec is incomplete. The difference I see is that ATAPI PIO and ATA PIO and ATA DMA do a better job than ATAPI DMA does of getting the device and the host to agree over how many bytes were copied which way. I find the value of ATAPI UDMA vs. ATAPI PIO hard to nutshell: for ATAPI, with UDMA, we give up accurate byte counting, but we get back quick and CRC-checked copying of the bytes. I'm talking about a specific observable comparative disadvantage of ATAPI DMA. I'm talking about things anyone can see by looking at bus traces, not merely some theoretical issues. > ... Let's try a concrete example, a bus trace I remember well. Suppose an app passes -x "12 0 0 0 05 0" -i 5 thru Win 95 B to an ATAPI device. (That coded hex is an Inquiry for up to 5 bytes copied into a 5 byte buffer. People like 5 bytes because the additionalLength field appears at offset 4.) After CommandOut, a device built to spec will respond with x1F2 SectorCount & x03 = x02 DataIn and x1F5:1F4 Cylinder = ByteCount = x0005. Win 95 B will then hang, til its 7+/0.5s timeout. This is Windows, we have no source, ouch. But we can see the machine code executed in response to the INTRQ, and we see it calculates the number of 16-bit "word"s to copy as: n = (bytes / 2) = 5 / 2 = 2 The correct calculation, seen in Win 98 (maybe not before 98SE?), taken from Computer Engineering 101, is of course: n = ((bytes + 2 - 1) / 2) = 6 / 2 = 3 We see a hang because 2 < 3. After copying two 16-bit "word"s, the host (wrongly) thinks the data transfer is complete, and waits (forever) for the StatusIn INTRQ. But the device is waiting (forever) for the host to copy the third "word". All this you can see, just by looking. This is not theory, this is fact. So far so good? > > spec will respond with ... x0005. Pedantically, we can argue than in place of x0005 we might see the sequence x 0004 0001, or the sequence x 0002 0002 0001, but those alternate sequences don't change the argument here. If ever the ByteCount is odd, Win 95 B hangs. (x0001 hangs it best.) Besides, in practice, those alternate sequences are rare, because the initial x1F5:1F4 Cylinder = ByteCount limit is x0005 or larger, or disregarded. > ... So we see, if we switch to ATAPI PIO from SCSI, things break. Not all data transfer modes are created equal. And the device can't fix this alone. Here, for example, devices have been seen to value Windows over ANSI and round up x0005 to x0006. But with Win 95 B, if the app buffer really is 5, then the bytes remaining to be copied In are calculated as ((unsigned short) (5 - x0006)) == xFFFF and life goes downhill from there in ways I no longer exactly remember. Even though the device can't fix this along, here there's nothing missing from the ATAPI PIO T13 committee work: here T13 faithfully reproduced the spirit of the SFF original. Here, when the host changes to comply with the T13 specification, the compliant device suddenly starts working. Kudos to T13. > ... Let's now suppose instead of ATAPI PIO, we use ATAPI DMA. A compliant device will assert DMARQ for three 16-bit "word"s. Nothing on the bus during the data transfer tells the host that the device thinks the last byte is a pad byte. That's an observable difference. Fact, not theory. The ATAPI PIO protocol, as specified first by SFF and then later by T13, is more redundant than ATAPI DMA. So far so good? > ... If we can agree that the ATAPI PIO protocol, as specified, is more redundant than the ATAPI DMA protocol, then we have begun to see how it could be that correctly implemented ATAPI PIO does a better job than correctly implemented ATAPI DMA does of getting the device and the host to agree over how many bytes were copied which way. Pat LaVarre
