Re: Scheduled Transfer Protocol on Linux

From: Larry McVoy (lm@bitmover.com)
Date: Sun Feb 13 2000 - 16:12:55 EST


: In message <200002132058.MAA22259@work.bitmover.com>, Larry McVoy writes:
: +-----
: | : | Imagine Linux with STP in the kernel on _both_ ends of the connection.
: | :
: | : Right, "simple" NASD drives in a private SAN. This differs from SCSI
: | : exactly how?
: |
: | SCSI already runs layered on top of STP just fine, so to some extent it
: | doesn't differ at all.
: +--->8
:
: I wasn't so much interested in that level as the one where SCSI is itself a
: networking protocol. Current SCSI drives are effectively IDE drives with
: on-board computers that do SCSI "networking"; at this level, smart drives
: with STP networking differ only in that they're potentially a little more
: general, and that you need to use slightly newer (but common) hardware and
: code to implement it.

I think we're not communicating. SCSI assumes the ability to transfer
large blocks. What SCSI performance be like if the largest transfer
was 1500 bytes? STP solves that problem (and the flow control problem
as well as some others). These problems just don't exist in the SCSI
world, SCSI implicitly assumes a DMA like interface where there is no
limit on the size of the DMA (well, certainly not a 1500 byte limit,
some older systems maxed out at 32 or 64K size transfers).

Am I missing knowledge of some advance in SCSI?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:25 EST