P1394 Mail Archive: Re: P1394> 1284.4 over SBP-2

P1394 Mail Archive: Re: P1394> 1284.4 over SBP-2

Re: P1394> 1284.4 over SBP-2

Atsushi_Nakamura (atsnaka@bsd.canon.co.jp)
Sat, 14 Feb 1998 10:40:40 +0900

To All,

>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

chosen to be THE transport for PC printing, and we will work the "glue"

for it. Has it ?

This is a very important decision, and I have not heard anything

"official" about it. (Did I miss something in one of the meetings ?

I apologize if I did.)

IP over1394 ?, thin protocol(DPP)?, AVC? ...

Nothing negative about SBP-2, I just want to take I thing at a time.

On the other hand, if we decide to use 1284.4, the natural way of thinking

technically is to come up with a "glue" ( or SBP-2 subset, which was once

proposed but turned down) between 1284.4 and 1394, since 1284.4

and SBP-2 has overlapping functionality.

I don't think anyone is planning on doing that.

I would like to consider supporting B, IF we have decided to use

SBP-2 for PC printing.

Eric' s note about Taigate and native-bridge was very convincing,

and I also think the same kind of situationt applies fro the printing world.

The HPT proposal, along with Alan's January proposal are 2 details

of the "B" work, which is similar to the direction the strorage protocol

went from Tailgate to native-bridge, which I think is the natural way of

thinking purely technically.

Ats Nakamura

At 22:33 98/02/09 -0800, Eric Anderson wrote:


> 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.



<bigger>Atsushi Nakamura


BJ Technology Develpoment 22,

Canon Inc.

53 Imai Kami-cho

Nakahara-Ku, Kawasaki-shi

postal no. 211