P1394 Mail Archive: P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

P1394 Mail Archive: P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

P1394> Re: SBP-2 vs. DPP 0.71 Cheat Sheet (?)

Greg Shue (gregs@sdd.hp.com)
Mon, 23 Feb 1998 09:36:08 -0800 (PST)

>
> Hi Greg,
>
> [You wrote]
> >What do you think?
>
> I have question that which is your prefer to use for PC Printing. So
> far, I thought you recommend to use SBP-2 for PC Printing. However, I
> could not distinguish advantage to use SBP-2 for PC Printing in your
> comparison chart.

I intentionally avoided stating preferences. I wanted to present
an "equivalent concept" chart, and see where the discussion goes.

> I feel that you are going to love THIN stack for PC Printing for keeping
> consistency with Peer-to-Peer devices. Who does want to be fat for same
> function?

OK, here's my preference...

"I am going to love using SBP-2 for peer-to-peer!

(And, with a different SBP-2 command set, I'll love using it
in a different way for PC printing!)"

Why? Because:

- Microsoft is supporting the SCSI model for scanning,
so the standard scanning solution is built around SBP-2

- Microsoft and Apple both prefer SBP-2 for printing,
so I prefer an SBP-2 based printing protocol.

- I want to support both PC printing and peer-to-peer
interactions, so both protocols are going to exist.
I don't see customers buying a printer which only
supports peer-to-peer.

As such, the SBP-2 based version only costs me the command set.
I'm already paying for everything else (testing, ROM space, RAM
space, tool support). And, when I want to, I can easily build
in access to other devices which use SBP-2 (e.g. disk drives).

No part of the Thin protocol comes for free. And it may only
work for the DPP protocol.

To quote an interrested party:
"Who does want to be fat for same function?" :-) :-)

I am quite aware of product cost. The "idea" of a $300 camera
was mentioned as a cost-costrained device. Let's not forget
about the "idea" of a $500 MFP which prints, scans and faxes.
They basically exist now... I would guess that they are
equivalently constrained, and the MFP must support a greater
variety of functionality (and protocols).

Also:

I have no idea how the "30K +/- 10K" number fits into my
environment. There were:

- no processors identified (CISC vs. RISC?),
- no toolsets identified (C vs. C++? vendor A vs. vendor B),
- no optimizations specified (none vs. compact vs. loop unrolling),
- no design parameters identified (speed vs. space).

(Hey, I might be able to do it in 10K! Then again it might
take 40K!)

Those early numbers I shared really say that:

sizeof(link driver) ~= sizeof(bus mgr) ~=
sizeof(SBP-2 initiator) ~= sizeof(spb-2 target) ~=
sizeof(IP1394 glue layer) ~= (1/3 -> 1/2) * sizeof(TCP/IP stack)

Please don't get hung up on the absolute number of "30K".
Besides, If you can't afford "30K" for the combined SBP-2
layers, then you probably can't afford "30K" for the software
to support a 1394 node, and you probably can't afford 1394 HW.

(And, here is another reality check: how big are ROMs these
days? Don't they come in practical package sizes of >= 0.5
MBytes these days? I have a hard time believing that anyone is
considering putting 1394 in a product where they have less than
7% headroom of one ROM package before they know what the
technology really takes!)

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			gregs@sdd.hp.com
----------------------------------------------------------------