From owner-freebsd-scsi Mon Jun 16 22:59:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA25005 for freebsd-scsi-outgoing; Mon, 16 Jun 1997 22:59:53 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA24992 for ; Mon, 16 Jun 1997 22:59:48 -0700 (PDT) Received: (qmail 17470 invoked by uid 1000); 17 Jun 1997 05:59:42 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 16 Jun 1997 22:59:42 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: Announcement: New DPT RAID Controller Driver Available Cc: FreeBSD-hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG, "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 17-Jun-97 you wrote: ... > Nope, the point was making was that you say the board has a 68030, > while > www.dtp.com says it is a 68040. The 68040 has quite a bit more kick than > a 68030. That's a good thing. This whole thing was atounge in cheek (foot in mouth?) and relates to some past employment experience... ... > The i960 is not necessarily better. Especially, not the gutless 20mhz > version. > > DPT might be better off with the 68060, as long as the price is right. Yes, but the logo on the chip is still wrong. Now take Mylex for example. Here is a quality, mature product that has the right high tech processor on board. Obviously the right choice. (Hint: Check out the Unholy union's benchmarks and performance braggings. Count how many DPT's are described and hoe many politically correct HBA's are listed. Now repeat once the i960 DPT's are out.) ... > How does this work? Do you need to buy DPT enclosures for this? You can. They are actually made by DEC Storage Works division. There is an upcoming SCSI standard for all this. The way it works is simple. They use several ``undefined/unused'' signals on the SCSI bus (cable) to transmit back and forth the necessary data. the DPT's simply comply with the DEC de-facto standard. We are using these enclosues in a HUGE project we are working on. It is amusing to pull a power supply, fan, disk or even a SCSI cable off while doing ls -alR or some nasty RDBMS access and listen to the siren, watch the red lights flash like mad and still have the disks operate as if nothing happened (well, a bit slower on RAID-5). > I don't have a DPT enclosure :(, and it doesn't seem that DPT makes > rack mount enclosures. Well, guess what? Call DPT, ask for Rene norton and tell her to sell you the same rack-mount she shipped me for evaluation. It is a rack mount that has 2 power supplies and 6 3.5" slots, or you can take a P/S out and put a 7th disk in. If you want, she can send you the proper terminator and instructions and then you can split the BUS into 2 busses. The only objection I hear here: a. The P/S are only available in A/C. We need -48VDC b. Both power and signal cables come off the front. this is great for service but our marketing people are complaining. We (Atlas Telecom, my employer) are building an AC-D/C version (using the DEC power supplies (3 in N+1), fans, SCSI backplane, etc. in our own box. It will have eight slots, be differential capable and allow bus daisy-chaining. It is done is cooperation with DPT and DEC so you should be able to enjoy the fruits of this effort. I have evaluated, tested and even participated in the design of more than one I/O subsystem in my short life. The StorageWorks solution is the best I have ever seen. not perfect, Just the BEST. Same goes for DPT. I have worked with them on several projects for over 15 years. Never dissapointed, except for minor things. ... > > disks are hot pluggable without any software intervention? > > Again these all sound like features in the hardware module? The hot-spare capability is a DPT feature. So it will work regardless of the disk cabinetry. Hot-plugging SCSI (especially single-ended is tricky. DPt helps out by allowing the use of 528 byte sectors. Coupled with ECC memory in the controller, they perform ECC across the SCSI bus. This cuts down (drastically) on the complaints at insert/removal. If your SCSI bus is not carefully done, you will still glitch it. I have tested some very reputable solutions and wit hthe exception of the StorageWorks, they all fail. The test is simple; Plug and unplug a drive once per minute and observe the system console. If you get tons of aborts (or the DPT beeps like mad and will not stop you have a bad disk bay. What happens is that either the power supply lines glitch and cause several drives to spin down (The DPT sees it as a multiple-drive fault and refuses to play the effected array), or it glitches some of the handshake signals and causes the bus to hang. The way DEC gets over that is with some fancy circuitry inside the disk module. the bus is totally passive (albeit interesting in design). > I just use standard hot-swap modules (Dataport VI). FreeBSD gets > mighty > confused when you pull a drive while it is running, but the modules are > mighty handle for any kind of field replacement. See above for possible causes. The DPT HBA handles all the recovery. You simply do not see any of it unless it gave up. If you WANT to address devices directly and eliminate the DPT handling (why?), there is a way to do it. The initial version of the FreeBSD driver does not support this ``feature''. > > Are power supplies a big deal these days? I've never had a good PS2 > supply die, but have had 4 drives die, all in last three years. Power supplies are funny business. We were having severe problems with a 250W PS/2 power supply handling insersions/removal of 4 drives in another disk bay. The StorageWorks does fine with one 150W P/S handling 8 drives. Has a lot to do with surge/spike/EMI handling on the OUTPUT side. Also, one may think that a $400 P/S may have some more design and quality put into it than a $35 one. Simon