This message is from the T13 list server.
Pat,
>From your email:
"> 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).
Not exactly.
By interpreting the command block, the device decides only the max count
of bytes it may transfer
The device may cut this transfer short arbitrarily."
That is not correct.
The problem here is that you keep on mixing up DATA IN (like INQUIRY
commands) and DATA OUT (like WRITE commands). Different rules apply to the
different directions, due to the different roles of the host and device.
Your quote of my email was explicitly on DATA OUT transfers (i.e. the host
to send more data). The example you bring up - INQUIRY - is a DATA IN. The
rules for DATA IN and DATA OUT are generally difference, signified by the
use of the phrase ALLOCATION LENGTH for DATA IN and TRANSFER LENGTH (or
PARAMETER LIST LENGTH) for DATA OUT.
While the device can send fewer bytes than the host indicated in the
ALLOCATION LENGTH value, the host CAN NEVER SEND FEWER BYTES than that
indicated in the TRANSFER LENGTH or PARAMETER LIST LENGTH (as I indicated in
earlier emails).
This is the source of the confusion - SCSI is not symmetric in handling DATA
IN and DATA OUT (it is not just a different direction!). Once you see that,
then things become clear.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 19, 2001 9:17 AM
To: [EMAIL PROTECTED]
Subject: [t13] actual Scsi byte count decided how?
This message is from the T13 list server.
> Jim ... Hale ... Mark ... other Jim ... Michael ... Harlan .. Tony ...
Thanks everyone for beginning/continuing to work to clue me in. I'll work
to reply to everyone in turn, but first ...
> > In direct-attached byte-wide Scsi, ...
> > ... an actual byte count that is
> > the min of those two max counts actually moves.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/18/01 01:48PM
> Your comment ... Confuses me.
Ahhh. This is key. We probably will get nowhere until we get me straight
on this much. Let's try focusing here for a moment.
> Are you thinking of REQ/ACK transitions?
Not exactly.
> ... Eventually the REQ/ACK offset would get to zero,
> but that does NOT signify command termination.
Just to keep our examples simple, let's stay for awhile with the slow full
handshakes of the original byte-wide "asynchronous" Scsi. For me this means
working from a human memory of 1995, but I trust you'll correct me where I
err.
In the original byte-wide asynchronous Scsi, the device waits indefinitely
for the host to answer each new REQ clock with an ACK clock. With each REQ
clock, the device says to move data or not, in or out, by de/asserting
C/D:I/O with each REQ.
In the simple circumstances analogous to Atapi Pio, the Scsi host & device
move just command, data, and status in that order.
The Scsi host & device discover the actual byte count of data transferred as
soon as the device stops asking to move data and starts asking to move
status.
So far so good?
> 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).
Not exactly.
By interpreting the command block, the device decides only the max count of
bytes it may transfer
The device may cut this transfer short arbitrarily.
The standard requires the device to cut transfers short on occasion. A
perhaps familiar example of cutting transfer short is:
x 12 0 0 0 FF 0 /i xFF
This six byte Cdb is an Inquiry for up to xFF bytes. The Scsi standard
requires the device to cut the transfer short without error unless it
happens to have xFF bytes of Inquiry data available.
A less commonly familiar example of cutting transfer short is:
x 12 0 0 0 FF 0 /i x1000
Here the host has allocated even more than the allocation of xFF bytes that
a command block with this x12 opcode can express. Nothing in the byte-wide
asynchronous Scsi protocol lets the device distinguish this case from the
case where the host allocated xFF bytes. Still the device cuts the data
transfer short after moving however many Inquiry bytes it has available.
A still less commonly familiar example of cutting transfer short is:
x 3B 0 02:00:00:00 0 01:FD 0 /o x1000
Here the host has allocated more than the x1FD minimum allocation that this
command block demands. Nothing in the byte-wide asynchronous Scsi protocol
lets the device distinguish this case from an allocation of precisely x1FD
bytes. Still the Scsi standard requires the device to cut the data transfer
short, this time after moving the max x1FD count of bytes that its
interpretation of this command block permits.
So far so good?
> > In direct-attached byte-wide Scsi,
> > the host and the device
> > each decide a max count of bytes
> > that will move [whichever] 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.
This I standby, so if it's not now obviously true to you, then we're not
using the same words to mean the same thing. Can you help me guess which
words are at issue?
I'm saying in Scsi, therefore likewise in Atapi, the host & device cooperate
to decide the byte count that actually moves, without ever actually
communicating the max permissible byte count that each has decoded
independently and more or less indirectly from the command block.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
