This message is from the T13 list server.
Pat,
> > The device [during DATA OUT] may cut this transfer short
arbitrarily.
> That is not correct.
Eh? Hmmm.
Let me try first to echo what you say, you tell me if I've heard you
accurately?
Let H be the max count of data bytes that the standard says a
command block may move.
Let D be the actual count of data bytes that the device requests to
move.
When moving data OUT for any standard command block, Scsi requires D
= H else an error.
Is that what you said?
With this, I agree, for each of the few standard command blocks that
I know.
You now have it right- D = H (using your terminology) for SCSI DATA OUT
commands. It has to be this way due to the nature of the SCSI parallel
interface (for which the command set was originally devised). That is, a
host that tried to change this after the command is issued would violate the
standard and/or hang the system. You're only out at that point is aborting
the command (e.g. with a RESET) and issuing it again at later time.
On your detailed questions, see inserted comments with a JPM.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 4:43 AM
To: [EMAIL PROTECTED]
Subject: Re: RE: [t13] actual Scsi byte count decided how?
This message is from the T13 list server.
> From: "Mcgrath, Jim" <[EMAIL PROTECTED]>
> Date: Wednesday - December 19, 2001 5:40 PM
> > x 12 0 0 0 FF 0 /i xFF
> > x 12 0 0 0 FF 0 /i x1000
> > x 3B 0 02:00:00:00 0 01:FD 0 /o x1000
> you keep on mixing up
> DATA IN (like INQUIRY commands)
> and DATA OUT (like WRITE commands).
Ah. Fun. I meant well. Often people like familiar analogies.
Given that now we say here we don't like this analogy, I'm ok drawing a
sharp Three way distinction:
1) host NOT wanting to move data in,
2) host wanting to move data IN,
3) host wanting to move data OUT.
I think in the discussion to date I only remain confused over the
thinking re moving data OUT. Only there do I see Atapi UDma 33 byte counts
differing from Pio by as much as 5, like x202 instead of x1FD, where other
people here by contrast see no differences larger than 1, like just x1FE
instead of x1FD.
> > The device may cut this transfer short arbitrarily.
> That is not correct.
Eh? Hmmm.
Let me try first to echo what you say, you tell me if I've heard you
accurately?
Let H be the max count of data bytes that the standard says a
command block may move.
Let D be the actual count of data bytes that the device requests to
move.
When moving data OUT for any standard command block, Scsi requires D
= H else an error.
Is that what you said?
With this, I agree, for each of the few standard command blocks that
I know.
> you tell me if I've heard you accurately?
I don't understand why this is relevant.
I mean to get us on the same page regarding how byte-wide
asychronous Scsi decides how many bytes move, without again falling away
into discussions of how Microsoft & friends should have written their code
so that more rarely do we have to care how mny bytes move.
I mean to focus on how byte-wide asynchronous Scsi decides D, apart
from H.
May I ask you to read again the following, focusing only on how true
or false it is for moving data OUT, at least temporarily ignoring how true
or false it is for NOT moving data and for moving data IN?
"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.
JPM - almost. The C/D, I/O lines are not asserted or deasserted during a
DATA PHASE (like DATA OUT) - they are kept constant. Indeed, it is the
changing of these lines that remove you from DATA PHASE. The device does
wait (forever if nothing else happens) for the host to send a bye in
response to a REQ.
"In the simple circumstances analogous to Atapi Pio, the Scsi host &
device move just command, data, and status in that order.
JPM - That's a bit too imprecise. It's better to say that in a successful
command operation the device goes from COMMAND to DATA (it any) to STATUS,
with possible intervening messages and disconnects, for a command). In an
unsuccessful command you can get stranger stuff.
"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.
JPM - This is totally incorrect. On a successful command the byte count is
determined by the parameter the host initially passed to the device in the
command block for the command length. The device will continue Requesting
data until that limit is reached. It will NEVER ask for less or more data.
Once again, an unsuccessful command will do stranger things (i.e. the
command can be terminated by the device early).
Jim
No?
If yes, then in summary we can say "the device may cut the data
transfer short arbitrarily", but the Scsi standard only "requires the device
to cut transfers short on occasion".
"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.
Thanks again in advance. Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
