PJohansson at aol.com
PJohansson at aol.com
Mon Feb 24 21:49:23 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* PJohansson at aol.com
In a message dated 97-02-24 19:15:50 EST, f_campbell at qlc.com (Frank Campbell)
<<There are aspects of SBP-2 which I believe should give rise to concern:
1. SBP-2 requires that targets deal with scatter/gather and paging issues
within the host.
2. SBP-2 requires that targets have the capability to break transfers up on
odd byte boundaries.
3. SBP-2 uses host addresses as handles with no means of identifying stale
handles, exposing the risk of stale handles causing corruption.
4. SBP-2 uses more bus transactions than necessary to perform I/O. As a
worst case example, a single sector read from disk requires up to 14 bus
arbitration cycles and 14 packet transfers.
5. SBP-2 hosts use DMA addresses supplied by targets, creating security
Items 1,2 and 4 relate to the cost and complexity of target hardware and
firmware. Items 3 and 5 relate to reliability and security.>>
These are interesting questions, Frank, that sound as if they will be posed
as public review comments at that stage in the SBP-2 development cycle. I
think that some of them are very arguable, as in "...more bus transactions
than necessary...". Compared to what, on 1394? But that is not the point of
this reply, which is:
What does this have to do with SBP?
If anyone believes (and can demonstrate) that SBP is LESS onerous with
respect to these matters or if anyone knows of credible SBP implementations
or planned implementations, they should speak up. Gene Milligan expressed
some skepticism about claims that SBP-2 is ready for prime time, but I didn't
take them as advocacy for SBP.
The heart of my suggestion to withdraw SBP rests on SBP's own merits---or
lack thereof. SBP certainly forms the foundation upon which SBP-2 was
developed; SBP-2 acknowledges this heritage and the valuable work that went
into SBP. BUT, SBP does not (in my personal opinion) represent a transport
protocol likely to be implemented. When I put forth the motion I did, it is a
way to ascertain if enough others share this view to withdraw SBP.
Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA 94602
(510) 531-2942 FAX
pjohansson at aol.com
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10