Let me chime in and see if I confuse or help this discussion.
I gather from the discussion that some form of automation is being attempted when transferring blocks to/from an ATAPI device, without the host having to interpret the SCSI commands or be told how long the transfer is to be.
The transfer length of the data within one COMMAND is defined by the format of the SCSI command which the ATAPI device can understand, that length may or may not be know at the outset. In most cases variable length data can be broken into a fixed length element that contains the length of the remaining data, and then subsequent requests to pick up the rest, however that does require the host to understand "SCSI".
Using the PIO protocol the data transfer can be broken into several blocks (bursts) of data, the size of which is negotiated between the host and the device, with the device having ultimate control. If the transfer is an odd length of Bytes this can be accommodated by a pad Byte, and the receiving end can discard it because the length negotiated are in Bytes (not words).
With UDMA the length of the transfer is not negotiable between the host and device. However the device can terminate the command when it determines enough data has been received or sent. Again the device can flow control the data by either pausing the flow or by breaking the data transfer into bursts. However the length of the burst or the "pause point" are not precisely defined. With UDMA the receiving end requests a pause but it may take several transfers for the data flow to stop (see ATA-4 on wards). Thus if the device wants to control data into its buffer it should anticipate when it needs to pause and give some headroom. If the device is receiving data and it determines that all the data has been received yet more is coming it has to discard the excess and terminate the command. If the transfer length is an odd number of Bytes it should cope with the pad Byte. Otherwise this should indicate that the host is messed up, the host should never transfer more than is specified (except for the pad Byte).
The only confusion over burst lengths from the devices point of view involves the words that are transferred after the device pauses a data out (i.e. to the device) burst. These words are part of the total word count for the command.
A host should never send more words than specified (Byte count plus pad Byte if needed). It would be possible to build a host that would receive data without prior knowledge of the transfer length it expects given it uses flow control to manage its buffers etc. However such a host could not distinguish between an even or odd Byte transfer length without being able to understand SCSI commands and the implied higher level of protocol.
-----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.
