This message is from the T13 list server.
Pat,
Your comment:
"In direct-attached byte-wide Scsi, the host and the device each decide
a max count of bytes that will move each way. Whenever host & device
agree on direction, an actual byte count that is the min of those two
max counts actually moves. It is the clash of this model with Ide Dma
that is giving me pain. It disturbs me that we don't all agree this
clash is as severe as it looks to me."
Confuses me. Are you thinking of REQ/ACK transitions? They are NOT
agreements between the host and device on the number of bytes to transfer,
and no "min of two numbers" algorithm is ever applied. For the sender of
the data it is simply the clock signal, similar to that used in UDMA. For
the receiver, it is the flow control line just like PAUSE is in UDMA. The
only difference is that SCSI uses word credits and UDMA uses a start/stop
signaling.
Specifically, if the device just had knowledge of the REQ/ACK signals it
could NOT properly terminate commands. Eventually the REQ/ACK offset would
get to zero, but that does NOT signify command termination. The device
would just wait endlessly for the host to send more data. It is only the
command level values of TRANSFER LENGTH and PARAMETER LIST LENGTH that allow
the device to determine, when compared to the total number of ACKs received,
that the command is over (and so terminate it).
I'll discuss your WRITE BUFFER example in the next reply.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 8:51 AM
To: [EMAIL PROTECTED]
Subject: RE: [t13] significant byte counts other than the total
This message is from the T13 list server.
> Harlan Andrews <[EMAIL PROTECTED]> 12/17/01 07:35PM
> ...
> I still don't see the problem.
Again I thank every one here for your remarkably continued patience &
courteous interest. I think/hope we're all focused in the same place now:
all the English I see now is slippery in exactly the right spot.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/17/01 04:39PM
> ...
> In SCSI the device always has responsibility
> for the correct termination of a command
Yes. Yes. Yes.
In direct-attached byte-wide Scsi, the host and the device each decide a max
count of bytes that will move each way. Whenever host & device agree on
direction, an actual byte count that is the min of those two max counts
actually moves. It is the clash of this model with Ide Dma that is giving
me pain. It disturbs me that we don't all agree this clash is as severe as
it looks to me.
> Harlan Andrews <[EMAIL PROTECTED]> 12/17/01 07:35PM
> ...
> >... perhaps we can agree that with UDma
> > we will see more data move than we did with Pio?
> UDMA and PIO should always move exactly
> the same amount of DATA for the completed command.
> You keep talking about:
> byte counts inaccurate by as much as X * 2 + 1, rising with burst rate
> You MUST be confused about the INTERMEDIATE bursts.
I was confused this way in the beginning - but I think I am no longer.
I'm saying, with Atapi Dma, we cannot always distinguish intermediate from
final bursts until after the burst ends.
If anyone here thinks somehow we can know in advance which burst is final,
please tell me how.
Given that we cannot know in advance which burst will be the final burst,
then we cannot know which bursts are intermediate, therefore we cannot know
if more bytes clocked across the bus than the device would have "willingly
requested" in Atapi Pio mode.
With Atapi Pio, the device decides the byte length of each burst, thus the
total byte length transferred. With most forms of Atapi Dma, the device
decides the "word" length of each burst, thus the total "word" length
transferred.
But with Atapi UDma Out, any time the device agrees to move more than zero
yet less than the count of bytes the host expected, the device does not
decide the total "word" length. By continuing to clock "word"s out during
the turnaround time past when the device asked to pause, a UDma Out host can
force the transfer of an extra X "word"s, with max X = 2 for UDma 33 and
rising with burst rate.
> a UDma Out host can force the transfer of an extra X "word"s
After so much discussion, this now seems very plain to me. I can't seem to
persuade anyone to answer this directly? Mostly I hear about why I
shouldn't care. On occasion I hear a flat denial that I'm seeing what I'm
seeing.
Can anyone tell me specifically what is unreal about my simulations?
(I say "simulation" because just now I'm working remotely. A colleague with
a bus analyser saw the same imprecision last week in the real world, but I
think the specific byte counts at issue may have been different.)
An example simulation is:
x 3B 0 02 00:00:00 0 01:FD 0 /o x1000
Here we've told our host to allocate and pin a x1000 byte physical page of
memory. Our cb (command block) is a standard WriteBuffer of x1FD bytes.
With Atapi Pio, in the bus trace, we see x1FD bytes requested. We see (x1FD
+ 1) / x2 = xFF clocks of data sent.
The imprecision over which we all agree I think, is that with Atapi Dma, we
see an indistinguishable xFF clocks of data again even if the cb is
different, even if we try a standard WriteBuffer of x1FE bytes:
x 3B 0 02 00:00:00 0 01:FE 0 /o x1000
The imprecision over which we have not yet agreed is that with UDma Data Out
we sometimes see x100 or x101 clocks, depending on how full the host's fifo
was when the device asked to pause and then terminate after xFF clocks.
In short, Ide Dma makes nonzero but unexpectedly short byte counts
inaccurate by as much as X * 2 + 1, rising with burst rate.
No?
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
