In case it got lost in the flurry Friday, I'm going to restate now the one technical
point on which I imagine we wall want to achieve consensus, no matter how we all then
agree to disagree over the most profitable business models.
Please tell me that and how I'm wrong?
I think there is no dispute over: Given N * 2 as the count of bytes the receiver and
the sender of clocks mutually agree clocked across the bus, given R as the count of
bytes the receiver of clocks means to transfer,
(N * 2 - R) may be as large as
(X * 2 + 1).
The question being debated is how large is (X * 2 + 1) in practice.
To say the non-communication of non-whole-block residue is only ever an issue for odd
byte counts is to claim max X is always 0. Me, I think see a max X of 2 in UDma 33,
rising with increasing burst rate.
Whatever max X truly is, this is a real issue for block transfers whenever the block
size is less than
((max X) * 2 + 2), thus an issue for non-whole-block transfers generally.
Please tell me that and how I'm wrong?
Thanks again in advance. Pat LaVarre
--- Begin Message ---
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.
--- End Message ---
