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.
Sincerely,
--------------------------------------
Eric Anderson ewa@apple.com
Apple Computer, Inc. 408-974-8187
--------------------------------------
> Hello Everyone,
>
> I'm sending this message to see if we can stimulate some discussion on
this
> subject prior to the 1394PWG meeting in Austin next month.
>
> For the past year we have been meeting to develop a standard to provide
the
> high functionality transport method for printing over the IEEE 1394
> interface. This is 'high functionality' , or 'thick' transport, as
opposed
> to the 'thin' transport that is being developed by the PWG-C. The
> direction that our group has taken has involved reviewing FCP, DFA,
SBP-2,
> and others, as the lower transport and datalink interface, with something
> else as the transport interface. This something else has focused on
1284.4
> or on a native 'glue' layer to the underlying datalink.
>
> At this point in time we have apparently narrowed our potential solutions
> to the following:
>
> A- 1284.4 with SBP-2
> B- New SBP-2 command set with SBP-2
>
> As many of you are aware, I'm primarily in support of option A as the
> preferred solution. I'd like to take this opportunity to provide some of
> my reasoning and get feedback from you.
>
> My support for this solution is not necessarily a technical reason, but a
> market reason. As Greg Shue et al pointed out at the Maui meeting, it is
> possible to provide the required functionality by defining a new Command
> Set for SBP-2. This would provide a transport solution for 1394 that is
> based solely on the SBP-2 protocol. Technically, this is probably a
better
> solution than option A.
>
> My question is "Is this really the best solution for the market today?".
> Many of us have expended great effort in developing the IEEE P1284.4
> standard. One of the purposes and goals of the development was to
create
> a datalink independent transport standard that could be used over the
> parallel port and other physical interfaces.
>
> The intent here was to create a standard that would allow a peripheral to
> operate over various interfaces without requiring major architectural
> changes to the product. In other words, a modular approach to the
> peripheral design. A printer or MFP device could be developed to work
with
> 1284.4 over parallel today, and 'easily' adapted to work over 1394
> tomorrow. The host application interface may not even know the
difference.
>
> I think that this is the primary reasons for choosing option A. It sends
a
> clear statement to peripheral and OS vendors that 1284.4 is the preferred
> transport interface for printer and MFP peripherals. We back this up by
> providing solutions for parallel (1284.3) and for 1394. This is not a
> stagnant industry and certainly new interfaces will appear in the future.
> I think it would be a great service that we provide a clear migration
path
> between interfaces that do not require redesign of the entire system.
>
> Providing both options may be the result of this effort. I think that
> option A should be the preferred one.
>
> I await your responses.
>
> Thanks,
> Larry
>
>
> ***************************************************************
> Larry A. Stein Phone: (619)292-2742
> Warp Nine Engineering Fax: (619)292-8020
> Web: http://www.fapo.com
> ***************************************************************