P1394 Mail Archive: Re: P1394> Some question about Command Set Proposal Revision 0d

P1394 Mail Archive: Re: P1394> Some question about Command Set Proposal Revision 0d

Re: P1394> Some question about Command Set Proposal Revision 0d

Greg Shue (gregs@sdd.hp.com)
Tue, 25 Aug 1998 09:28:09 -0700 (PDT)

Hi Johnson,

> If the Target is a scanner, the initiator is a PC host. There would be

This depends on the size of buffers associated with the ORBs.
This is effectively determined by the host driver and target engineers.

The less data the target can buffer, and/or the smaller the buffers
queued by the initiator, the higher the overhead. It's a design
tradeoff. The only constraint imposed by the command set is that
a data buffer is limited in size to < 2 GBytes. If this doesn't
allow for an appropriate system solution, then this isn't the
right transport, and 1394 may not be the appropriate I/O technology.

Maybe a specific example would help:

If a target (e.g. a scroll-fed scanner) has enough memory to
buffer up 8 MBytes of data, then it can capture that much of an
image to memory and be able to re-transmit it as many times as
needed. It may need to do this more than once if a
transmission is interrupted by a Bus Reset (or cable
disconnect/reconnect). This retransmission capability lets the
target indicate a MAX_T2I_DATA_SIZE of 8 MBytes.

An initiator may decide that it doesn't want to dedicate as
much kernel memory as the target could handle to keep the
system flowing (e.g. 2-4 * 8 MBytes). It would then decide to
queue up smaller ORBs, and more ORBs and acknowledgements would
take place.

> If the scanner has four modes,
> (i) A4 size 16bit fullcolor
> (ii) A4 size B/W 2 color
> (iii) B4 size 16bit fullcolor
> (iv) B4 size B/W 2 color.

NOTE - Without a pixel resolution, this says nothing about how
much data is being moved. At 75 ppi for an A size page, full
bleed, uncompressed, 16 bit/pixel, only 1,052,700 Bytes (<1.004 MB)
will be moved. When that becomes 2400 ppi @ 32 bits/pixel, the
same image takes >2.006 GBytes!

> which solution is correct ?
> (a) the initiator would allocate memory for each mode.
> (b) the initiator would just allocate only one maximum size
> memory which is found out by TRANSPORT_CAPABILITES
> request.
> If the solution is (b). It doesn't have good performance in
> host's OS.
> And If the initiator find out that the data buffer is less than
> the target's maximum size. which one is correct???
> (c) the initiator will stop this ORB. delete it from the list.
> (d) the initiator would seperate the Target's data into several
> T2I ORBs. When the initator's data buffer is full, initiator
> will put them into disk or append them into a file.
> But this cause a problem. The target cannot know initiator's
> data buffer is full.

Much depends on what you mean by 'correct'. One thing you'll
have to be aware of is: don't think of this transport as being
used like a disk drive! It's much more appropriate to think of
it as being used to access a serial communications device.

Options a) and b) may not be physically possible.

Option c) is in violation of the Transport Cmd Set doc.
Initiators are not allowed to delete an ORB from the list.

Option d) is the expected running condition. A target can (and
must) always know when an initiator's ORB is full, since it is
filling it. A scanner also can (and must) always know when the
scan is done. As long as a TRANSPORT_T2I_DATA ORB exists, the
target can send any data it has.

You must choose for yourself the appropriate sizes.

Also, don't forget that there is nothing prohibiting a scanner
from directly using SCSI on SBP-2. This is just a generic
transport. It is certainly not appropriate for some things (e.g.
video). It is an appropriate replacement for the 1284 port
protocol stack if the 1284 solution expects a transport like this
one. The device engineers can model it any way they desire.

> I do not really know what is message-based service and stream-based
> service. I should miss these paragraph in specification. Could you please
> explain these to me??? Thanks.

See the PWG Transport Protocol draft. It's explaination is
outside the scope of the command set document. The difference is
really in the API to the transport and affects how the transport
is used. The easiest explanation is done with examples:

- TCP/IP provides a connection-oriented bidirectional stream
service. The receiver of information has no idea of how the
data was broken up when passed to the transport. It only
knows that it was done sequentially.

- The in-order message based-service _does_ let the receiver
know how the sender pieced the information together at the
Transport API.

Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com