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.
