This message is from the T13 list server.
Pat,
"Still looks to me - and to a number of people working in partnership
with me
- like UDma Out can clock OUT across the bus as many as maxX * 2 + 1
bytes
more out than AtapiPio would move, whenever the receiver tries to cut
the
transfer short before the sender does, provided the sender didn't
coincidentally
delay for a turnaround, with maxX = 2 for UDma 33 and rising with burst
rate.
ATAPI PIO "allows" the clocking out of a number of bytes set by the receiver
- the device - based on its available buffer resources. UDMA does exactly
the same thing. In this case the receiver indicates it is running short of
resources in real time using the PAUSE capability, rather than trying to
make a guess ahead of time with Byte Count. The receiver never drops any
bytes in the process (otherwise BAD DEVICE) in either case. As Hale and I
keep on pointing out, you're trying to require something that just is not
needed (i.e. will operate just fine in a system).
The only level at which you need to worry about the number of bytes is the
command level. There you just have to not send out more bytes than allowed
by the command. Obviously if you were cracking the command yourself you
would know this number (just as a host does). But the host sending you the
data packets also knows the correct number. Specifically, if you have to
send down exactly 234 bytes for a command to a device, the host simply will
not send you more than 234 bytes. Once you have sent the last byte to the
device, the device will see that the command is completed and tell you that.
If the host is sending you more bytes than you should have for the command,
then it is a bad host (as Hale would say). Specifically, USB sets a maximum
packet size, but the last packet for any command can be a smaller size in
order to make the byte count come out correct - and the packet size is set
at the byte level of granularity.
I have no doubt that there are some host implementations that violate
various standards (ATA, ATAPI, SCSI, USB, et al), but in doing so they lose
the benefit of interoperability (which may be OK for them, but they have to
live with the consequences). A lot of people spend a lot of time and money
to comply with these standards. So there has to be resistance to requests
for changes that make up for broken implementations, since it rewards those
who are not doing their part to achieve an interoperable world. If everyone
did that then no one would interoperate.
Once again, does not mean someone making ATAPI devices would not be
interested in making up for someone else'e error in implementation. But
it's not at first glance a standards issue. It only becomes one if enough
of those device suppliers see a real business opportunity for themselves.
Since our products don't suffer any of these problems, I'll leave it to
others to carry it on from there.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 14, 2001 3:16 PM
To: [EMAIL PROTECTED]
Subject: RE: [t13] a PIO example
This message is from the T13 list server.
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 12/14/01 03:00PM >>>
> ...
> So for a host who understands commands there should be no issue.
> So in Pat's case, he should be safe in transferring the extra byte
> and having the host take case of it (i.e. the host has
> to understand it is an SFF-8020 issue,
> even using the USB or other interface,
> which is reasonable to me since this is a command level,
> not a transport level, issue).
> ...
I'm not caught up on all the traffic, in particular not all the tutorials
that seem to have been kindly written precisely for my benefit, but I saw
this ...
Some (lots of?) hosts still thinks they are talking Scsi. All the other
stuff is a port of the Scsi stuff. The more or less open source of Linux
and Mac OS X explicitly express life this way: not Scsi stuff is a "subclass
derived from" Scsi, dunno about Wintel.
Some plug 'n play code uses info from inside the system to see how Scsi a
device is or is not: rumour tells me FireWire devices can talk to some
flavours of Windows without bothering to implement op x12 Inquiry (!!!).
Other plug 'n play code issues problematic commands like op x12 Inquiry in
order to discover what kind of device is connected. That code can't know a
given device will respond creatively to odd byte counts until it is too
late.
Agreed the Ansi text tells a host & device how to cooperate well enough to
never clock IN across the bus more than 1 SwDma/UDma, never more than 3
MwDma, bytes beyond what AtapiPio would move.
Still looks to me - and to a number of people working in partnership with me
- like UDma Out can clock OUT across the bus as many as maxX * 2 + 1 bytes
more out than AtapiPio would move, whenever the receiver tries to cut the
transfer short before the sender does, provided the sender didn't
coincidentally delay for a turnaround, with maxX = 2 for UDma 33 and rising
with burst rate.
But maybe after I comprehend the tutorials presented here lately, I'll clue
in to how wrong I am. Wish me well.
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
