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@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@cbj.canon.co.jp
email(2):atsnaka@bsd.canon.co.jp
-----------------------------------------