The transaction direction is completely different and so requires
a completely different mechanism.
To illustrate the difference:
Data flows from PC to printer
PC runs out of credit, so issues a CreditRequest to the printer.
Printer gives the CreditRequestReply back to the PC.
NOTE: This must be done immediately to allow the PC to
do other command trasactions and avoid blocking the CBT
channel. Otherwise, additional command channel credits
must be supported and must exist.
Since this must be done immediately, it may be returned with
zero credit. In this case, the PC will not ask for additional
credit because the printer remembers the request and will
_spontaneously_ give credit when buffer space is available.
This is done with a Credit/CreditReply transaction initiated
by the printer, not another CreditRequest/CreditRequestReply!
PC waits for more credit, WITHOUT polling for credit.
Printer has buffer space available for PC, so fills out a
Credit packet to be sent to the printer...
How is this packet sent?
What needs to happen is the PC needs to read the packet,
process it, and send a CreditReply packet in response!
The mechanisms beneath the CBT protocol need to support this,
and so we must understand _exactly_ how this is done
since the Credit packet from the printer could be ready
at _any_ point in time.
The difference between Credit and CreditRequest is similar to
the difference between data push and data pull.
CBT & SBP-2 combined could never match SBP-2 by itself in terms of
performance. The overhead of explicit credit management guarantees
that.
Fumio Nagasaka wrote:
>
> Greg Shue wrote:
> >To highlight the issue:
> > Exactly how does an initiator peer which supports CBT receive a
> > Credit packet from the target at any indeterminate time?
> >This is not provided directly by 1284.4. How are you planning on
> >solving it for your implementation of option A?
>
> 1) The initiator place “CreditRequest” packet in an out-ORB.
> 2) If the target find an in-ORB in the linked list of ORBs, target
> fill out
> the buffer associated this ORB with “CreditRequestReply”
> packet.
> 3) If the target could not find any in-ORB in the linked list of
> ORB,
> then the target send unsolicited status which requests the initiator
> to provide an in-ORB in the list. Then go to step #2.
>
> Am I missing any steps?
> I think step #3 becomes overhead. So CBT supportive SBP-2 profile
> does not mark higher speed than pure SBP-2 transaction.
>
> --------------------------------------------
> -------------------------------
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111, Fax +81 268 25 4627
> E-mail to nagasaka.fumio@exc.epson.co.jp
>
> -----Original Message-----
> From: Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent: Friday, February 13, 1998 4:58 AM
> To: pp1394 ML
> Subject: [PP1394:00147] Re: P1394> 1284.4 over
> SBP-2
>
> >
> > This message is in MIME format. Since your mail reader
> does not understand
> > this format, some or all of this message may not be
> legible.
> >
> > ------ =_NextPart_000_01BD3784.4C5B70D6
> > Content-Type: text/plain
> >
> > Dear Eric,
> > Dear Larry,
> >
> > Please find an attached document which shows issue
> Eric and myself
> > had discussed at December 3, 1997.
> > <<Generation.PDF>>
> > I am writing printer drivers that covers first
> generation of 1394
> > printing.
> > These printer drivers are supporting option A.
> > <<
> > A- 1284.4 with SBP-2
> > B- New SBP-2 command set with SBP-2
> > >>
> > I also prefer to choose option A at least in these
> couple of years. One
> > of my reason is market reason same as Larry. Another
> my reason is
> > technical reason. As I mentioned before, a target peer
> which supports
> > CBT allows initiator peers to send ORBs safely. Any
> data link layer
> > which services only one data path has difficulties to
> support multiple
> > logical channels. Because, if once one of logical
> channels had been
> > stalled, other requests that goes same data path will
> be stalled.
> > The CBT set the data link layer free from these
> difficulties.
>
> Yes, any link which supports only one data path has
> difficulties
> to support multiple logical channels.
>
> This is exactly why I identified the major issue between
> option A
> and option B as whether multiple functions within a
> device are
> provided via:
>
> MUX layer for multiple functions access presented as
> one Unit (option A)
> vs.
> separate units for each function (option B)
>
> This is really the choice between the two options.
>
>
>
> The other topic of discussion under this thread deals
> with how to
> use SBP-2 to provide independent, opposing,
> unidirectional data
> streams over the same login. Whether option A or option
> B is
> chosen, the issue of providing the specified
> bidirectional
> service to the layer above SBP-2 still exists. And, I
> think it's
> exactly the same issue.
>
> To highlight the issue:
>
> Exactly how does an initiator peer which supports CBT
> receive
> a Credit packet from the target at any indeterminate
> time?
>
> This is not provided directly by 1284.4. How are you
> planning on
> solving it for your implementation of option A?
>
>
> > -------------------------------
> > Fumio Nagasaka
> > Epson Software Development Laboratory Inc.
> > Tel +81 268 25 4111, Fax +81 268 25 4627
> > E-mail to nagasaka.fumio@exc.epson.co.jp
>
>
> --
> Greg Shue
> Hewlett-Packard Company
> Office Products
> Division gregs@sdd.hp.com
>
> ----------------------------------------------------------------
>
-- Greg Shue Hewlett-Packard Company Office Products Division gregs@sdd.hp.com ----------------------------------------------------------------