UmVjZWl2ZWQ6IGZyb20gcGFscmVsMS5ocC5jb20gKHBhbHJlbDEuaHAuY29tIFsxNS44MS4x
NjguMTBdKSBieSB2ZW51cy5yb3NlLmhwLmNvbSB3aXRoIEVTTVRQICg4LjcuMS84LjcuMyBU
SVMgNS4wIE9wZW5tYWlsKSBpZCBKQUEwNTMxMyBmb3IgPGFsYW5fYmVya2VtYUBocC1yb3Nl
dmlsbGUtb20yLm9tLmhwLmNvbT47IFRodSwgMyBTZXAgMTk5OCAwOTozNzowMCAtMDcwMCAo
UERUKQpSZWNlaXZlZDogZnJvbSBjYW5vbmdhdGUuaW4uY2Fub24uY28uanAgKGNhbm9uZ2F0
ZS5pbi5jYW5vbi5jby5qcCBbMTUwLjYxLjQuNV0pCglieSBwYWxyZWwxLmhwLmNvbSAoOC44
LjYvOC44LjV0aXMpIHdpdGggRVNNVFAgaWQgSkFBMDU5NzYKCWZvciA8YWxhbl9iZXJrZW1h
QGhwLmNvbT47IFRodSwgMyBTZXAgMTk5OCAwOTozNjo1OCAtMDcwMCAoUERUKQpSZWNlaXZl
ZDogKGZyb20gdXVjcEBsb2NhbGhvc3QpCglieSBjYW5vbmdhdGUuaW4uY2Fub24uY28uanAg
KDguOC44LzMuNlcpIGlkIEJBQTA0NTYwOwoJRnJpLCA0IFNlcCAxOTk4IDAxOjM2OjU2ICsw
OTAwIChKU1QpClJlY2VpdmVkOiBmcm9tIGlzdncxLmNlY24uY2Fub24uY28uanAoMTUwLjYx
LjguMTUyKSBieSBjYW5vbmdhdGUgdmlhIHNtYXAgKFYyLjEpCglpZCB4bWEwMDQ1NTA7IEZy
aSwgNCBTZXAgOTggMDE6MzY6MjkgKzA5MDAKUmVjZWl2ZWQ6IGZyb20gY2Fub25ndy5jZWNu
LmNhbm9uLmNvLmpwIChsb2NhbGhvc3QgWzEyNy4wLjAuMV0pCglieSBpc3Z3MS5jZWNuLmNh
bm9uLmNvLmpwICg4LjguOC8zLjZXKSB3aXRoIFNNVFAgaWQgQkFBMDMzODc7CglGcmksIDQg
U2VwIDE5OTggMDE6MzY6MjggKzA5MDAgKEpTVCkKUmVjZWl2ZWQ6IGZyb20gaHVycmljYW5l
LmNwZGMuY2Fub24uY28uanAgKHJvb3RAaHVycmljYW5lLmNwZGMuY2Fub24uY28uanAgWzE1
MC42MS44LjMxXSkKCWJ5IGNhbm9uZ3cuY2Vjbi5jYW5vbi5jby5qcCAoOC44LjgvMy42Vykg
d2l0aCBFU01UUCBpZCBCQUEwNjg3MTsKCUZyaSwgNCBTZXAgMTk5OCAwMTozNjoyOCArMDkw
MCAoSlNUKQpSZWNlaXZlZDogZnJvbSBjcGRjLmNhbm9uLmNvLmpwIChzaGltdXJhQGxvY2Fs
aG9zdCBbMTI3LjAuMC4xXSkKCWJ5IGh1cnJpY2FuZS5jcGRjLmNhbm9uLmNvLmpwICg4Ljku
MWEvMy43Vy0xOTk4LzA4LzI2KSB3aXRoIFNNVFAgaWQgQkFBMTA5MzI7CglGcmksIDQgU2Vw
IDE5OTggMDE6MzY6MjIgKzA5MDAgKEpTVCkKRGF0ZTogRnJpLCA0IFNlcCA5OCAwMTozNjoy
MSArMDkwMApQb3N0ZWQ6IFRodSwgMyBTZXAgMTk5OCAwOTozNTo0NyAtMDcwMCAoUERUKQpG
cm9tOiBHcmVnIFNodWUgPGdyZWdzQHNkZC5ocC5jb20+ClJlcGx5LVRvOiBwcDEzOTRAY3Bk
Yy5jYW5vbi5jby5qcApTdWJqZWN0OiBbUFAxMzk0OjAwMzMxXSBSZTogUDEzOTQ+IDEzOTQg
VGltZXJzPwpUbzogcHAxMzk0QGNwZGMuY2Fub24uY28uanAgKHBwMTM5NCBNTCksIE5hZ2Fz
YWthLkZ1bWlvQGV4Yy5lcHNvbi5jby5qcApDYzogcHAxMzk0QGNwZGMuY2Fub24uY28uanAK
TWVzc2FnZS1JZDogPDE5OTgwOTAzMTYzNS5KQUEyNTM5MkBocHNkbGdqMS5zZGQuaHAuY29t
PgpJbi1SZXBseS1UbzogPDE5OTgwOTAzMDE0OS5LQUEyNDc3MUBzbXRwMS5kdGkubmUuanA+
IGZyb20gIkZ1bWlvIE5hZ2FzYWthIiBhdCBTZXAgMywgOTggMTA6NDk6MzMgYW0KWC1NTC1O
YW1lOiBwcDEzOTQKWC1NYWlsLUNvdW50OiAwMDMzMQpYLU1MU2VydmVyOiBmbWwgW2ZtbCAy
LjFBIzddOyBwb3N0IG9ubHkgZnJvbSBhbnlvbmUKWC1NTC1JbmZvOiBJZiB5b3UgaGF2ZSBh
IHF1ZXN0aW9uLCBzZW5kIGEgbWFpbCB3aXRoIHRoZSBib2R5CgkiIyBoZWxwIiAod2l0aG91
dCBxdW90ZXMpIHRvIHRoZSBhZGRyZXNzIHBwMTM5NC1yZXF1ZXN0QGNwZGMuY2Fub24uY28u
anAKTWltZS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0
PVVTLUFTQ0lJCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKUHJlY2VkZW5jZTog
bGlzdApMaW5lczogNzcK
--openmail-part-14cf2839-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline; filename="[PP1394:00331]"
Content-Transfer-Encoding: 7bit
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@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@sdd.hp.com ------------------------------------------------------------------openmail-part-14cf2839-00000001--