Date: 08 Oct 1999 15:18:06 +0000 From: Randell Jesup <rjesup@wgate.com> To: scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <ybuaept6fv5.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Mike Smith's message of "Fri, 08 Oct 1999 11:35:52 -0700" References: <199910081835.LAA00821@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Gerard Roudier <groudier@club-internet.fr> writes:
>I invite you to read my previous postings about this topic and will just
>post the following output from iostat I got using 2 10K disk on a single
>SYM53C896 channel (I have described the test conditions in a previous
>posting):
>
>(Cheetah2 LVD + DRVS LVD)
>
> tty da0 da1 da2 cpu
> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
> 0 0 4.00 4461 17.43 4.00 4460 17.42 0.00 0 0.00 3 0 56 14 27
> 0 0 4.00 4461 17.42 4.00 4462 17.43 0.00 0 0.00 3 0 52 16 29
>The sym_hipd driver is also very fast using 53C875 and 895 controllers. I
>cannot perform CCD testings at the moment since I donnot have time enough
>for that, but I have some additionnal benchmarks I could flood the list
>with.
Nice results. I haven't played with 53c8xx chips, but I wrote some
very fast drivers for the 53c7xx chips a long time ago ('93) for the Amiga.
I'd planned to support full CAM for that and for the 53c90(? I forget), but
never got the time to finish it (I wrote/tested the XPT and some other
parts (partial SIM)). (Amiga's had a mostly-equivalent of CAM called
SCSIDirect.)
>On the result above (sequential read), may-be disconnections are not so
>frequent, but I know the reselection path of the sym_hipd driver enough
>to claim that this path is also very fast and certainly faster than the
>ncr since it is just O(1) for both SCRIPTS and C code with regards to
>the number of concurrent IOs (all that from 810A to C1010).
The 53c7xx was missing some important abilities (like an ALU!), but
you could do some cool things to avoid interrupting the processor. In
particular, I supported reselection without processor interrupts -
disconnect would cause modifications to the code-path for reselection.
(The structures for tracking active requests included code used to
determine if that was the request asking for reselection; on disconnect it
was linked into the tree of code for "we have a reconnect"). This included
tagged commands. I still have the code kicking around somewhere.
I'm not sure my setup was O(1), but it was pretty good (probably
O(log(n)), maybe O(n) where n is number of active requests per target.
If it's O(n), then making it O(log(n)) would be trivial by using a (b)tree
instead of a list.
FYI, I was also on the "section 10" CAM working group that rewrote
the target-mode part of CAM from the ground up after I discovered it was
totally un-implementable and informed them. Target-mode is potentially
handy for very-high-speed short-distance networking, as well as for
situations where you want machines to have direct access the same drives,
etc. I know DEC implemented section 10 of CAM (several of the other
section 10 people were from DEC).
I'm now working using FreeBSD machines, and figured I'd see what
was up in the disk-driver area of FreeBSD. I also wrote all the IDE
drivers for Commodore (based on SCSI emulation - I made a SCSIDirect
(CAM-like)-to-IDE conversion layer, so IDE drives appeared to be SCSI.
Ditto for ATAPI. I was also the primary FS person in later days there, and
added the "dir-cache" extensions (and something that was mostly the
equivalent to "soft-updates"), and worked on the peer-to-peer networking
code (which used RDP).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuaept6fv5.fsf>