[t13] H = C = D of course

Pat LaVarre LAVARRE at iomega.com
Thu Feb 20 09:01:10 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
[[[I've dropped t10 at t10.org to BC, so if someone there
wants to see the rest of this thread, that person must
reply.]]]

> From: Hale Landis [mailto:hlandis at indra.com] 
> Sent: Thu 2/13/2003 12:11 AM 

> Hale said:
> >> The "host" and device shall understand what the
> >> command means and both shall have the same
> >> expectations for any "data stream" transferred by
> >> that command on the physical interface.
> 
> Pat replied:
> >Maybe they shall, but in fact, commonly, they don't.

Indeed.

> no I/O works unless the host and device agree.

False.

I/O works if eventually host & device agree enough.
They don't have to agree in advance.  They don't have
to agree completely.

And again I say, commonly, they don't agree.  This
isn't purely a matter of opinion, this is largely a
matter of experiment.  Depending on what we talk Scsi
over, setting up a trigger to see if host & device
agree can be more or less difficult.

Usb Mass can be easiest.  One of the options in Usb
Mass is to make a device that STALL's the Usb bus
whenever host & device do disagree.  STALL is a
"token" - recognised by every form of Usb bus trace
trigger I've ever seen.

By substituting such a Usb Mass device for another
Scsi-over-whatever device with an identical protocol,
such as a precisely equivalent Atapi device, in a bus
trace we can observe how often the host & device
disagree.

Even in an Atapi bus trace, if we happen to have a
host that sets the PIO ByteCountLimit to H, then we
can see how very commonly in fact H != D.

> When they don't agree you have a major data
> integrity or I/O interface protocol problem to deal
> with.

True.

> For example, when a host constructs a data stream
> for a write command the host shall understand the
> length of that data stream and the contents of that
> data stream.  When the device receives that write
> command it shall have the same understanding of
> that command's data stream.  If not, ...

That "shall" is empty.  "If not" is reality.  I'm
arguing to grow the scope of  T13 texts to the min
necessary to make talking actually work.

> If not, then what happens? Some, but not all, of
> the host data is sent to the device?

This varies.  De facto, people do a great job for D
< H of block data, an ok job for D < H of byte data,
and the details vary wildly when H < D.

They can't do better than an ok job when D < H for
byte data, because T13 doesn't let a bus trace count
the bytes copied, because there is no standard way to
say the last N bytes were just pad i.e. not mutually
agreed to be copied.

> Some of the data is ignored by the device?

The host & device cooperate to decide what happens.

Commonly, the extra data gets dropped, often not even
appearing clocked across the bus, when D < H.

When H < D, some hosts ignore/fabricate data In/Out.
Others sample noise.  Others hang.

> The device expects more data than the host is able
> to provide (resulting in a hung ATA/ATAPI device -
> device waiting for more data)?

Can happen.

> There is only one solution that works: The host and
> device have the exact same understanding of the
> command and the command's data stream.

Not true.  Transport can be robust enough to cope,
indeed often is.

> For example, when a host contructs a read command
> the host probably has a good idea of the maximum
> length data stream it will receive

The host has an opinion: an interpretation of the Cdb.
The device has an opinion too, formed more or less
independently.

In Scsi over FireWire and Scsi over Usb, the device
can see the host's opinion.  In Scsi over Ide Pio (aka
Atapi Pio), the host can see the device's opinion.

Any time hardware/ firmware/ software can see both
opinions, it can work to resolve conflicts.

> the host ... probably has a good idea what valid
> data stream contents are (especially for SCSI
> command like INQUIRY, MODE SENSE, REQUEST SENSE).

Again, an opinion, often wrong in fact.

> I used "probably" because some read commands are
> allowed to transfer a variable amount of data. When
> the device receives that read command it will
> construct a data stream to send to the host.  There
> are several valid things that could happen: the
> device may send no data, the device may send some
> data, the device may send the maximum amount of
> data.

If the max is not agreed out of band in advance, then
the device may send more than that.

> There is a problem if the device wants to send more
> data than the host wants (again, resulting in a
> hung ATA/ATAPI device - device waiting for the host
> to accept the remaining data).

Again H < D yes.

> So again, there is only one solution that works:
> the host and device have the exact same
> understanding of the command and the command's data
> stream.

This sounds unreal to me.  Since I know Hale is sane,
I conclude I'm not understanding the English.  Offline
we're still working to rephrase.

Pat LaVarre

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list