[PP1394:00331] Re: P1394> 1394 Timers?

[PP1394:00331] Re: P1394> 1394 Timers?

Atsushi_Nakamura atsnaka at bsd.canon.co.jp
Thu Sep 3 20:18:30 EDT 1998


While I was ctching up with the thread, 
I noticed that this is going out ONLY on the PWG-C reflector,
not p1394 at pwg.org.

Is there something wrong with the PWG reflector (or my mailer) ?????

Ats

At 01:36 98/09/04 +0900, Greg Shue wrote:
> Fumio Nagasaka wrote:
> > I am just saying one existing transport design seems to be
> > better than current 1394 PWG commands set. We need to do
> > more effort. If someone improve the design and persuade me
> > to realize 1394 command set is better, I willingly agree
> > with the idea. If not, my idea is the 1394 PWG command set
> > shall be a data link layer to be utilized with other
> > transport command set.
> 
> When looking at a total solution, I don't see how the combination
> of (1284.4 + <data link cmd set> + SBP-2 + 1394) is "better"
> than what we have currently defined.  The <data link cmd set>
> would be slightly simpler than our current proposal, but
> it requires much more complexity to do 1284.4.  We'll end
> up with a much more efficient and lighter weight protocol.
> 
> > Greg Shue wrote:
> > >  -> Max amt of data
> > >     queuable:           as much memory as     max (negotiated) size
> > >                         allocated by device   transfer * MAX_TASK_SET_SIZE - 1
> > 
> > Ok, if you say "queeable", the max size queuable in memory
> > cannot exceed max size of memory allocated by Operating System.
> > Thus your description is misleading the discussion.
> > Our scanner OS will not allocate 2 GB for queuable memory
> > space. :-) This is just a specification writing technique.
> 
> In the case of SBP-2, the maximum size queuable on the Task List
> cannot exceed the max size of memory allocated by the initiator's
> operating system.  These are PCs with potentially lots of memory.
> In the case of 1284.4, the maximum size which can be transferred
> without having to issue credit is limited to the smallest amount
> dedicated at either end of the cable.  For the same configuration,
> would you rather have a 2 MB total limit or a 32 KB total limit?
> 
> > >
> > >  Defined SBP-2           No                | Yes
> > >  command set
> > 
> > This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
> > I mean 1284.4 is abstracted from any data link layer and it
> > does not have any dependency for data link design. If you
> > want to say your commands have some dependency for SBP-2
> > in words "defined SBP-2 command set", I feel it is better
> > to develop command set which does not have any dependency on
> > data link layer. We are defining transport layer.
> 
> Nope, we are defining a complete stack up through the transport
> layer.  This means we must also define the "data link" layer and
> how to glue them together.  Without an SBP-2 command set, there
> is no SBP-2 based solution.
> 
> > Let's clear the points;
> > I'm not saying I would like to use 1284.4 over SBP-2.
> > This idea was eliminated in February. I am saying that we
> > shall develop something better than 1284.4 to utilize
> > SBP-2, or something just a data link layer which is
> > applicable for transport protocol. But in later case
> > each vendor need to choose or develop higher layer to
> > apply this data link. Thus I prefer first idea. We shall
> > develop something more effective than 1284.4 to utilize
> > SBP-2. May be Greg is thinking current command set
> > is better thna aother, but I am thinking we need to pay
> > more effort to exceed even 1284.4.
> 
> I'll agree with the first option.  And I think we are already
> doing that.  Specifically, what do you think needs to be improved
> or addressed?
> 
> The second option is counter-productive.  We're trying to
> come up with standards here.
> 
> -- 
> Greg Shue
> Hewlett-Packard Company
> All-in-One Division			        gregs at sdd.hp.com
> ----------------------------------------------------------------
>  
-----------------------------------------
Atsushi Nakamura
-----------------------------------------

BJ Technology Development 22,
Canon Inc.

53 Imai Kami-cho
Nakahara-Ku, Kawasaki-shi
postal no. 211

tel:+81-3-44-733-6111(ext.5593)
    +81-3-44-739-6634(direct)
fax:+81-3-44-739-6756
email(1):Atsushi_Nakamura at cbj.canon.co.jp
email(2):atsnaka at bsd.canon.co.jp
-----------------------------------------



More information about the P1394 mailing list