This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/06/01 18:01 PM > Pat, can you clarify Thanks for hanging in here with me. I hope you share my feeling that we inch forward with every exchange of email. > ... I would not employ a transfer counter ... > since that would require a real reworking of UDMA. > > Instead, for ... support ... byte residues, > just implement the counterpart > to the IGNORE WIDE RESIDUE message in SCSI > > - a register you can read > at the END of the command > that tells you whether the last byte[s were] > valid of not (e.g. 0 for valid, > [nonzero] for invalid). > > ... simple[] to implement > and if done right only [hosts and] devices > that can have [nonzero] residues need ever to change. Yes I mean to be asking for precisely that. But I can see we haven't yet confirmed/denied I'm right to think that standard UDma 33, for example, builds in an inaccuracy of up to 5 bytes. So far we're only talking about an inaccuracy of 1 and that only when byte counts are odd. Let's try to get me straight on that much, and then we can move on. > Pat, can you clarify We can talk about all the Ide data transfer protocols at once if we distinguish the sender of data clocks from the sender of data bits. In every mode except UDma Data IN, the host is the sender of clocks. In UDma Data IN, the device is the sender of clocks. In any Ide transfer, the sender and the receiver of clocks jointly observe N clocks of data. When then are they wrong to think they both have willingly exchanged N * 2 bytes of data? Well, the different data transfer modes give the sender and the receiver more or less power to cut short the stream of clocks. Suppose the sender of clocks wants to move at most S bytes. The sender stos sending clocks when N <= ((S + 1) / 2). That is, when (N * 2) <= S if S is even, else when (N * 2) <= (S + 1) if S is odd. So far I've said nothing new. The sender introduces an inaccuracy of 1 only when S is odd, no matter the transfer mode. But now let's suppose the receiver of clocks wants to move at most R bytes. The receiver stops clocks by telling the sender to stop them. As burst rates increase, turnaround time increases, and the sender runs on further past where the receiver wanted to stop. The receiver can only guarantee N <= ((R + 1) / 2) + X, where X is the count of eXtra clocks: the clocks the receiver unwillingly received. X is 0 for Pio/SwDma. X is technically 0 or 1 for MwDma, but 0 in practice. X rises with burst rate for UDma. I hear any of 0 1 2 for UDma 33, 0 1 2 3 for UDma 66, more for UDma 100, and so on. Agreed? In bus traces in the lab, I see some prejudice in favour of block counts. Whenever the sender and receiver agree over block size, if the sender of clocks delays the next clock after a block boundary for as long as a turnaround time, all these inaccuracies go away. Perhaps the inaccuracies really do go away this way with Ata devices: maybe the Ata insistence that all commands to a block device in fact move multiples of blocks makes this not much of an issue for Ata devices. By failing to delay for the turnaround time between each two data clocks, the sender & the receiver permit a max inaccuracy of (X * 2 + 1) in the count of bytes willingly exchanged. For UDma 33, max X is 2, so max inaccuracy is 5. Agreed? Without additional protocol, only the sender can know if S was odd. Only the receiver can know if R was odd and what X actually turned out to be. To let the host measure this inaccuracy precisely, when the device was the receiver of clocks, we need the device to report to the host X and if R was odd. When the device was the sender of clocks, we need the device to report only if S was odd: only the host can observe X when the hos is the receiver of clocks. We can solve all cases one way if we always require the device to report its "Ide Dma residue": the count of bytes it knows were exchanged unwillingly. If the device was the sender of clocks, the Ide Dma residue is 1 if S was odd, else 0. If the device was the receiver of clocks, the Ide Dma Residue is X * 2 + 1: in one number we communicate both what X was and if R was odd. Agreed? > who is sending these commands > for 5 bytes of returned INQUIRY data? I don't mean to be coy. I feel I face a chicken & egg situation here. My real world data on WHAT happens is pretty concrete: remembered Pio bus traces of plug 'n play dying when we step away from latest Windows on out to cover the Windows installed base and then out to cover the world beyond Windows. I also remember contrasts between shipping volumes of devices that do this well and devices that don't. I can only guess WHY host & device folk do such a poor job of coordinating their interpretation of commands. To agree how reasonable or unreasonable my guesses are, I think we need to agree first on WHAT the standard permits me to see in bus traces when we change only from Pio to UDma. Only then can we coherently argue out a reasonable guess of how small of subset of what I could see will I actually see. Thanks for talking. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
