A non-text attachment was scrubbed...
Name: 1.txt
Type: application/octet-stream
Size: 2013 bytes
Desc: not available
Url : http://www.pwg.org/archives/p1394/attachments/19980903/e7f0d54e/1-0001.obj
-------------- next part --------------
Wow! I am lost in the drift of this whole thread?
Does any of this still actually address timers?
Can someone summarize the salient points in a new topic?
Is there anything actionable for the profile?
Help....
Alan
______________________________ Reply Separator _________________________________
Subject: Re: [PP1394:00331] Re: P1394> 1394 Timers?
Author: gregs-at-sdd (gregs at sdd.hp.com) at HP-Roseville,mimegw3
Date: 9/3/98 9:36 AM
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
----------------------------------------------------------------