I am "Eric". I am the FireWire Software lead at Apple Computer.
You wrote:
"I love a symmetrical transport also. PC Printing has supported
1284, USB and 1394 soon. If you considers a symmetrical transport
for 1284, USB and 1394 (and IP), it will be great for us. To
redesign PC software only for a new 1394 print transport will be
tough."
Do you speak officially for Microsoft in Redmond? Is this a policy
statement that Microsoft will support 1284.4 over 1394 instead of
a pure SBP-2 native printer protocol? This would be very different
from Microsoft's position about Tailgate. The 1394 team in Redmond
has been quiet on this subject, so an official response would help.
Since you did not recognize my name, perhaps you did not see my
original message. A copy is attached below.
--------------------------------------
Eric Anderson ewa@apple.com
Apple Computer, Inc. 408-974-8187
--------------------------------------
============
== This letter was sent to p1394@pwg.org and P1284_3@lexmark.com
== by Eric Anderson (ewa@apple.com) on 98.02.09:
Hi Larry,
Since you asked, I'll try to politely explain my preference for
solution B: New SBP-2 command set with SBP-2. I regret that I
can't make a strong argument, because I haven't had the time to
track closely your progress with solution A. Still, I think
there are compelling reasons to consider solution B.
Recently, the 1394 community had the opportunity to define a
storage protocol for 1394. The first solution, Tailgate, gave
us essentially an ATA interface bridged over 1394. Both the
target and the initiator had to operate as if traditional ATA
was the interconnect. Sure, SBP-2 was present, but only as a
transport, and much of it's potential was wasted. Tailgate
was supposed to be quick an easy and lead to rapid market
adoption. What actually happened was quite different.
Microsoft and others realized that adopting this model would
"lock in" ATA for a long time, including long after ATA itself
was dead. Emulating a dead technology with new technology may
yield short-term savings in implementation, but at the expense of
long-term losses in performance. Amazingly, reason prevailed,
and Tailgate was abandoned in favor of a pure SBP-2 protocol
for disk drives. As it turned out, Tailgate vendors quickly
switched to Native Bridge, which still allowed today's drives
to act like 1394 drives, by making them look (from a 1394
point of view) like fully native devices. As far as I can tell
this switch was not too painful, and now we aren't stuck with
ATA. Everyone won.
Now we have a similar situation with printers. 1284.4 is a
very well established technology. Compared to 1394, I think it
would be fair to say that 1284.4 is also a very slow and clumsy
technology (nothing personal!). Surprise, surprise - the idea
comes up to bundle 1284.4 in SBP-2 because some purported savings
can be had, in the short term. From what I have seen of how this
works, it is quite inefficient, with lots of unsolicited status
requests and in general lots of hand-holding by the CPU on the
initiator. This is not what SBP-2 was designed for.
As printer resolutions climb, printer bandwidth rises very
quickly. Yes, we all still do dull black and white word
processing, but I think you printer vendors will agree that the
exciting (high-margin) areas are in con-tone large-format high-
speed printers - just the sort that need 1394. Or sparing that,
even consumer-level inkjets now have remarkable resolutions and
consume quite a lot of bandwidth.
Used properly, SBP-2 allows huge data transfers that can proceed
at the pace of the consumer (printer), with no hand-holding by
the host (computer). Since host systems have 32 or more megs of
RAM today, ideally, printing should proceed with at most one
interrupt per megabyte of data transferred (assuming no errors),
leaving the CPU free to do useful work (like rasterizing). SBP-2
and OpenHCI make this possible - but only if protocols are designed
with care to avoid needless interruption of the host.
Perhaps I have misunderstood your recent work regarding 1284.4 on
1394 in SBP-2, but I believe that the present plan will have far
more overhead than what I just described. Specifically, I believe
this overhead comes from carefully emulating 1284.4 rather than
using SBP-2 in it's most natural way. Over the lifetime of
1394, the cost of that overhead in wasted MIPS and wasted time will
far exceed any possible savings from recycling current protocols
and software.
1394 is far more "future friendly" and scalable than other
interconnects were at their introductions. That didn't stop
Ethernet, ATA, SCSI, Parallel Port, and the like from living as
useful technologies for one or two decades. Our goal should be
to make 1394 last at least as long, if not longer. Portability
of a protocol to new interconnects at the expense of efficiency
doesn't seem valuable to me in this context - in fact, it seems
counter-productive. The more inefficient the protocol we choose,
the more demand there will be for ever-faster interconnects. A
well-designed, efficient protocol can last a very long time, and
serve everyone's needs better during that time.
I hope I haven't gone too far overboard here or stepped too hard
on any toes. To conclude, I want to ask a simple question: Has
anyone run this idea past Microsoft? Microsoft killed off
Tailgate, and my guess is that they may have similar feelings
about printing. Market reality is that we'll all follow whatever
they decide, so it really makes sense to get them involved.
Alas, I can't join you in Austin, but I do welcome your comments
by email. Please be patient if you ask good (ie hard) questions.
============
> Nakamura-san,
>
> I still like to provide a same transport for PC software over the other
> printer interfaces. Printer manufactures have supported USB, 1284 and .4
for
> printers. I believe that no one like to develop software running only
with
> PWG specific 1394 printer protocol. We need consistency over any printing
> devices.
>
> Saying just 1284.4 over SBP-2 may cause some confusions. Have you
described
> what is inefficient to stack overlapping functionality and tried to
remove
> it from 1284.4 over SBP-2? Is supporting socket interface included in the
> latest proposal? If you have, I am sorry. My manager didn't allow me to
> travel to Maui, however I loved to be there. Can you update the latest
> status or a meeting memo in Maui? I need catching up you.
>
>
> By the way, who is Eric? Whom did he contact with in MS? Though I don't
own
> a storage, I would like to hear the story from him. If someone in MS had
> miscommunication with him, I can forward it to proprietary in MS.
>
> Thanks,
> Hitoshi
>
> > -----Original Message-----
> > From: Atsushi Nakamura [SMTP:atsnaka@mxa.mesh.ne.jp]
> > Sent: Sunday, February 15, 1998 7:35 PM
> > To: Hitoshi Sekine
> > Cc: 'PWG-C mailing'; p1284_3@lexmark.com; p1394@pwg.org
> > Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> >
> > For PWG printing,
> > We will have to decide whether not we use 1284.4 or not,
> > but in any case, it is inefficient to stack overlapping
> > functionality.
> > My choices would be either :
> >
> > 1) 1284.4 - "glue"- 1394
> > 2) "glue"or cmd set - SBP-2- 1394
> > 3) "glue"or cmd set - other transport(thin?)-1394
> >
> > I am yet uncertain which is the best( maybe 2) or 3) ),
> > but I DO have a opinion that in any case :
> > 1284.4 over SBP-2
> > is not my choice, because in this case;
> >
> > >Sure, SBP-2 was present, but only as a
> > >transport, and much of it's potential was wasted.
> >
> > would happen. (same for 1284.4)
> > Is using 1284.4 our first priority, or is using SBP-2 our
> > first priority ? (or something else? )(or using both !?)
> >
> > P.S I would like to refer to Eric's comment about the 1394 disks
> > again.
> > >Recently, the 1394 community had the opportunity to define a
> > >storage protocol for 1394. The first solution, Tailgate, gave
> > >us essentially an ATA interface bridged over 1394. Both the
> > >target and the initiator had to operate as if traditional ATA
> > >was the interconnect. Sure, SBP-2 was present, but only as a
> > >transport, and much of it's potential was wasted. Tailgate
> > >was supposed to be quick an easy and lead to rapid market
> > >adoption. What actually happened was quite different.
> >
> > I think this is the same situation with 1284.4 (as ATA) and
> > SBP-2 (or IP,Thin.... )
> >
> > >Microsoft and others realized that adopting this model would
> > >"lock in" ATA for a long time, including long after ATA itself
> > >was dead. Emulating a dead technology with new technology may
> > >yield short-term savings in implementation, but at the expense of
> > >long-term losses in performance. Amazingly, reason prevailed,
> > >and Tailgate was abandoned in favor of a pure SBP-2 protocol
> > >for disk drives. As it turned out, Tailgate vendors quickly
> > >switched to Native Bridge, which still allowed today's drives
> > >to act like 1394 drives, by making them look (from a 1394
> > >point of view) like fully native devices. As far as I can tell
> > >this switch was not too painful, and now we aren't stuck with
> > >ATA. Everyone won.
> >
> > Let's not repeat history....
> >
> >
> > -------------------------------------------------
> > Atsushi Nakamura
> > BJ Printing Technology 22
> > Canon Inc.
> > -------------------------------------------------
> >
> > -----Original Message-----
> > ??? : Hitoshi Sekine <hitoshis@microsoft.com>
> > ?? : 'Fumio Nagasaka' <fumiona@venus.dti.ne.jp>; 'Stephen Holmstead'
> > <stephen@hpb16977.boi.hp.com>; 'Toru Ueda' <ueda@slab.tnr.sharp.co.jp>;
> > Turner, Randy <rturner@sharplabs.com>
> > CC : 'Brian Batchelder' <brianb@vcd.hp.com>; p1394@pwg.org
> > <p1394@pwg.org>;
> > 'PWG-C mailing' <pp1394@cpdc.canon.co.jp>; 'p1284_3@lexmark.com'
> > <p1284_3@lexmark.com>
> > ?? : 1998?2?16? 7:21
> > ?? : RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> >
> >
> > >
> > >I love a symmetrical transport also. PC Printing has supported 1284,
USB
> > and
> > >1394 soon. If you considers a symmetrical transport for 1284, USB and
> > 1394
> > >(and IP), it will be great for us. To redesign PC software only for a
new
> > >1394 print transport will be tough. I don't mean to recommend
different
> > >solutions between PWG-C and PWG. We need to get our priorities right.
Not
> > to
> > >confuse PC software industry is my first priority.
> > >
> > >I personally understand that 1284.4 may be a bridge over those local
> > >interfaces and familiar with an IP printer.
> > >
> > >Hitoshi Sekine
> > >
> > >
> > >> -----Original Message-----
> > >> From: Fumio Nagasaka [SMTP:fumiona@venus.dti.ne.jp]
> > >> Sent: Saturday, February 14, 1998 9:04 PM
> > >> To: 'Stephen Holmstead'; 'Toru Ueda'; Turner, Randy
> > >> Cc: 'Brian Batchelder'; p1394@pwg.org; 'PWG-C mailing';
> > >> 'p1284_3@lexmark.com'; Hitoshi Sekine
> > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > >>
> > >> Dear Stephen,
> > >>
> > >> Your opinion bring us back to December 1996. Actually we started
from
> > >> this point.
> > >>
> > >> I would like to list up existing standards and some proposals here.
> > >>
> > >> Transaction architecture:
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> IEEE 1394 | Memory Bus
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> SBP-2 | Memory Bus
> > >> DPP | Stream (PWG-C / Toru Ueda)
> > >> TCP | Stream
> > >> DFA | Stream (PWG / Alan C. Berkema)
> > >> 1284.4 | no definition
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >>
> > >> Transaction style:
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> IEEE 1394 | push and pull, symmetrical
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >> SBP-2 | pull
> > >> DPP | push, symmetrical
> > >> TCP | push, symmetrical (may implement passive open)
> > >> DFA | push, symmetrical
> > >> 1284.4 | push control, symmetrical
> > >>
> >
-------------------------------------------------------------------------
> > -
> > >> ----------------
> > >>
> > >> Please correct if I had overlooked something or I am missing some
> > points.
> > >>
> > >> Stephen wrote:
> > >> <<
> > >> requirements). I would HATE to have to make a printer that
implemented
> > >> two different transports for PWG and PWG-C printing. I think most
> > >> printer manufacturers would agree.
> > >> >>
> > >>
> > >> No.
> > >> Due to some market reasons, printer manufactures are required
> > >> to support USB, conventional parallel port, 1394 and Macintosh
serial
> > >> interface. However Digital Camera (one of typical consumer imaging
> > >> device) does not support parallel port. Thus for some consumer
> > >> device manufactures, it is meaning less to have a solution which
> > >> provide common protocol stack to cover various existing interface.
> > >>
> > >> If PWG and PWG-C shall have same solution, I think we shall
> > >> have only one "Printer Working Group". However many Japanese
> > >> companies could not agree with this plan. They might have their own
> > >> reasons. And I think we ought to pay consideration for them.
> > >> --------------------------------------------
> > >> -------------------------------
> > >> Fumio Nagasaka
> > >> Epson Software Development Laboratory Inc.
> > >> Tel +81 268 25 4111, Fax +81 268 25 4627
> > >> E-mail to nagasaka.fumio@exc.epson.co.jp
> > >>
> > >> -----Original Message-----
> > >> From: Stephen Holmstead [SMTP:stephen@hpb16977.boi.hp.com]
> > >> Sent: Saturday, February 14, 1998 12:59 PM
> > >> To: 'Toru Ueda'; Turner, Randy
> > >> Cc: 'Stephen Holmstead'; 'Brian Batchelder'; p1394@pwg.org
> > >> Subject: RE: P1394> Rough SBP-2 & IP1394 core component ROM sizes
> > >>
> > >> I agree with Toru that we NEED a symmetrical transport. I really
don't
> > >> care which option (A or B) is used, as long as we can provide a
> > >> symmetrical connection. In fact, that was one of the PWG transport
> > >> requirements from that start, but it just seems that we have
accepted a
> > >> transport (SBP-2) that isn't symmetrical and we are calling it good.
> > >> The PWG-C also needs a symmetrical transport. I would love to have
the
> > >> same transport for the PWG and PWG-C (since they both have the same
> > >> requirements). I would HATE to have to make a printer that
implemented
> > >> two different transports for PWG and PWG-C printing. I think most
> > >> printer manufacturers would agree.
> > >>
> > >> Greg Shue said that he made a proposal to the January PWG that would
> > >> extend SBP-2 so that it was symmetrical (at least that is what I
> > >> understand--I may be way off here). If so, that would be great. I
> > have
> > >> not been able to find any minutes from the PWG since Dec 97 (anyone
got
> > >> some?).
> > >>
> > >> 1394 could really use a commonly accepted symmetrical transport
layer.
> > >> If that's 1284.4, great. If that's a modified SBP-2, great. If
that's
> > >> TCP/IP, great. If that's DPP's Thin Protocol, great.
> > >>
> > >> Personally, I am biased towards IP or 1284.4 (if you couldn't tell).
> > >>
> > >> Stephen Holmstead
> > >>
> >
> >
>