jensen%uiowa.csnet@csnet-relay.arpa (Nancy Jensen) (04/26/86)
We are in the process of upgrading our disk storage (long overdue). We are a VAX11/780 4.2BSD system, planning to go to 4.3 this summer. We are considering a couple of possibilities. I would really appreciate some "personal experience" feedback from anyone who has purchased the same drives and controller for a comparable system. The drives we are considering are: 1. Fujitsu M2361 (Eagle XP) and Spectralogic 111+ controller 2. CDC 9775 and Dilog DV215-2 controller. I'm interested in answers to questions such as: -is a device driver available under 4.2? 4.3? -is DEC doing your maintenance -general opinions, etc. As I said, ANY input would be GREATLY appreciated. Please mail direct. Thanks, Nancy Jensen Computer Science Department University of Iowa CSNET: jensen@uiowa
lacasse@rand-unix.arpa (04/26/86)
I would be careful on the the Spectralogic, as I don't think they have sold
many controllers and you will likely find Unix software support lower
because of this.
Dilog makes some nice controllers. I don't know about this one. They
aren't as popular as Emulex, but have some nice features Emulex doesn't
(flexible formating for any parameters of tracks, arms, etc; error
re-vectoring).
Emulex is the clear leader. You might consider their SC-7003. Its a new
product, 8 drives, 3.0 MB/S SMD. We have one on order ourselves.
We ordered it with the Fujitsu Eagle II (M2361) you mention. We figured
it is probably a good drive, since it is the same mechanically as the Eagle I
(M2351). We have about 10 of those, over a few years. We've had only
one failure.
If the CDC you mention is the 3.0MB/S one with about 800 MEG, we looked
at that too. It has good specs, and about the same price as the Eagle II.
We didn't take the time to find out if it was as reliable as the Eagle.
At the time (2 weeks ago) I was under the impression it had been out only
45 days. But it turns out that is just how long Emulex has been selling it.
Its been sold for Data Generals and such for something like a year. If
you find it is, or is not, as reliable as the Eagle, please let me know.
Mark LaCasse qantel!hplabs!sdcrdcf!randvax!lacasse
c/o The Rand Corporation cbosgd!ihnp4!sdcrdcf!randvax!lacasse
1700 Main Street lacasse@Rand-Unix
Santa Monica, CA 90406
213/393-0411 ext. 7420dms@mit-hermes.arpa (David M. Siegel) (04/30/86)
The 3.0 MB/S CDC drive has the same MTBF as the eagle and eagle II. In addition, its seek time it 16 ms average, compared with 18 ms for the eagle. All in all, it seems like a better drive than the eagle II.
grr@cbmvax.cbm.UUCP (George Robbins) (05/05/86)
In article <411@brl-smoke.ARPA> dms@mit-hermes.arpa writes: >The 3.0 MB/S CDC drive has the same MTBF as the eagle and eagle II. In >addition, its seek time it 16 ms average, compared with 18 ms for the >eagle. All in all, it seems like a better drive than the eagle II. I suggest you talk to some of the people who do third-party drive repair and refurbishment. My understanding is that CDC has a pretty mixed reputation and are now screwing themselves in the area of replacement parts availability and cost. Of course, you can always send your drive back to CDC for repairs :-)... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
henry@utzoo.UUCP (Henry Spencer) (05/08/86)
> The 3.0 MB/S CDC drive has the same MTBF as the eagle and eagle II...
On the spec sheet, or in practice? There is a difference. The Eagles
got their reputation for reliability from field experience, not because
everyone was awed by the spec sheet.
--
Join STRAW: the Society To Henry Spencer @ U of Toronto Zoology
Revile Ada Wholeheartedly {allegra,ihnp4,decvax,pyramid}!utzoo!henrygeoff@desint.UUCP (Geoff Kuenning) (05/10/86)
In article <411@brl-smoke.ARPA> dms@mit-hermes.arpa writes: >The 3.0 MB/S CDC drive has the same MTBF as the eagle and eagle II. In >addition, its seek time it 16 ms average, compared with 18 ms for the >eagle. All in all, it seems like a better drive than the eagle II. I presume the MTBF you are talking about is the manufacturer's spec in each case. If so, remember that in one case (CDC) you are talking about a number that is a theoretical calculation. On the other hand, the Eagle's reputation for reliability derives from experience in the field, not the manufacturer's MTBF spec, which may be much more conservative. For reference, a year is 8766 hours. If you plan on running 24-hours a day, a 10,000-hour MTBF is pretty poor. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
speck@cit-vax.Caltech.Edu (Don Speck) (05/12/86)
In article <299@brl-smoke.ARPA>, lacasse@rand-unix.arpa writes: > I would be careful on the the Spectralogic, as I don't think they have sold > many controllers and you will likely find Unix software support lower > because of this. > Emulex is the clear leader. You might consider their SC-7003. Its a new > product, 8 drives, 3.0 MB/S SMD. We have one on order ourselves. Emulex has as little Unix support as you can get: last I heard, they have no in-house Unix machines, only VMS. So they have no way of detecting those bugs that show up on Unix and not VMS. A year ago we bought a Fujitsu M2298K and Emulex SC7000. There's an option to map the drive as two DEC RM05's (wasting space), or unmapped. VMS has to use the former, but we wanted the latter; since we were probably the first non-VMS site to buy a 2298 from them, guess what - the unmapped mode didn't work. A couple days, new prom revision. At the same time we bought a tape drive and TC13 controller. I started loading the 4.2bsd distribution tape and find that standalone copy could read the tape, but the generic kernel couldn't. Much debugging later, I find that the TC13 is upset because the status buffer just happened to cross a 256-byte boundary - someone forgot to carry into the high byte of the address. Within the week, new prom revision (Rev. D). For a long time I observed that the clock on that machine lost many minutes whenever we did dumps. I figured my non-standard 'dump' was overloading the raw I/O system, which I knew spent lots of time at spl6(), but recently I figured out that it was the tape controller's fault. Another set of new proms (Rev. F). (Emulex was extremely cooperative once they knew that there was a problem, and in other respects their stuff has been great). My point is that the latest, greatest board is unlikely to have been debugged on a Unix VAX yet (they aren't as common as VMS). You are asking to be a guinea pig. It may be worth it - it was for us - but you'd better be aware that you're getting into that. Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speck
danny@itm.UUCP (Danny) (05/12/86)
In article <6666@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> The 3.0 MB/S CDC drive has the same MTBF as the eagle and eagle II... > >On the spec sheet, or in practice? There is a difference. The Eagles >got their reputation for reliability from field experience, not because >everyone was awed by the spec sheet. >-- >Henry Spencer @ U of Toronto Zoology Agreed. But, we have gone ahead anyway, based on out experience with our CDC 9715. We have installed a CDC 9772 drive. It's been in operation perhaps three months, without a problem yet. We have serial #105 (and according to our sales rep, serial numbers started with 100), and everything seems kosher. One interesting anomaly, however. We run System V.2 (called XELOS) on a Perkin Elmer 3210. After we started using the new disk heavily, we started losing time on the system clock. Not much, about 5 min/day. All we can figure is that the controller is interupting so quickly that the cpu misses some clock ticks. -- Danny Disclaimer: "I don't know nuthin': I wuz at church!" XELOS is a trademark of Concurrent Computer Corp. (nee Perkin Elmer) 3210 is also probably trademarked by the same. System V.2 is probably a trademark of AT&T. It is better to light one small candle in the dark, than to get all hot, bothered, and frustrated trying to light a grape. -- Daniel S. Cox ({siesmo!gatech|ihnp4!akgua}!itm!danny)