From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 17-MAY-1994 17:37:40.95 To: EVERHART CC: Subj: Re: Advice sought on choosing DEC discs and processors X-Newsgroups: comp.os.vms Subject: Re: Advice sought on choosing DEC discs and processors Message-Id: <1994May15.000054.12034@fallout.lonestar.org> From: system@fallout.lonestar.org Date: 15 May 94 00:00:54 CST Organization: DECUS DFWLUG BBS *Dallas*TX*214-270-3313 Lines: 191 To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article <768955428snz@kestrel.demon.co.uk>, ken@kestrel.demon.co.uk (Ken Harris) writes: > We are considering retiring our older VAX systems and expanding our dual 4100 > DSSI VAXcluster both in terms of discs and processors. In both cases I am > confused by the many apparently similar devices that DEC offer which makes > choosing the "best" device a real challenge. I would be very grateful for any > advice the net can offer based on my thoughts below. > > DISCS: > > I would appear to have three choices: > > 1. Additional DSSI discs. Since DSSI discs cost more than their SCSI > equivalents what advantages do DSSI discs offer? The obvious one of direct > sharing between up to 3 nodes has the downside of being limited to 8 devices > (including CPUs) on the bus. Is DSSI more efficient than SCSI? They > cannot be transferred to Alpha systems so may be a poor investment. WHY DSSI? DSSI disk drives have a built in optimizing controller, and can be accessed by two-three VAX/AXP hosts on the same DSSI bus. The Optimization takes up to the last 100 I/Os pending and reorders them to access all the data using as few "Elevator" Seeks (smooth pass across the disk geometry) as possible. An additional 128kb of cache exists on the controller ... It's as if Digital took the HSC technology and instead of using it for many disks, reduced it in size and are using this controller to optimizing a single disk. I've seen as high as 30-50% more sustained I/Os from a single DSSI disk than from it's SCSI counterpart. DSSI ON ALPHA DSSI busses are available for the DEC 2100 and the DEC 4000 600/700 line of alpha processors with the same availablity specs when dual hosted. Dual VAX/AXP hosts are easily supported using the DSSI as a cluster path today and for some time in the future. SCSI DOES NOT SUPPORT DUAL ACCESS METHODS TODAY. Digital showed a technology display at DECUS with two DECpc150s SCSI clustered but that technology is unavailable in current OpenVMS versions... > > 2. SCSI discs attached directly to SCSI port. Cheaper but discs have to be > shared over Ethernet, is this a real performance issue? Allows greater total > number of devices (DSSI plus SCSI). The DSSI Bus is currently rated at 1200 I/Os per second and 4Mbytes per second sustained. Serving Drives across a single ethernet would only be .9-1.2Mbytes per second. DSSI will outperform Ethernet by about 4X. FDDI cluster/MSCP service path is rated at about 10-12Mbytes/Sec (with no other network traffic) If you are considering using a network path to serve data.... Consider using FDDI...Supported today. > > 3. SCSI discs attached to DSSI via HSD05. Seems to be the best solution > allowing multiple lower cost discs to be directly shared by up to 3 nodes. > Can you have multiple HSD05s, each using one DSSI port but each having up > to 6 SCSI discs attached? Yes the only limitation I'm aware of is that currently the HSD05 cannot Contain or Be the system disk. Reuse of the Storage Works disks is desireable as long as the need for disk access is not above the HSD05's 2.5-3Mbyte/second rating. Putting Six SCSI drives on a single HSD05 will work but could limit over all performance. (You really have to be pushing the disks but any 2-3 could easily outrun the SCSI <-> DSSI controller rates... Two-three HSD05 controllers have the potential to overrun the DSSI Bus...) Four or Six DSSI disks will outperform (raw I/Os and Raw Mbytes) four or six HSD05 connect to a DSSI bus with four to six SCSI drives each. Of course the HSD05 will allow for much higher DENSITY than the current DSSI based disks can muster. This is the apparent trade offs of the two technologies. Your milage may vary based upon user workload... Do you need a Mustang or a Pick-up Truck;-) Both do different jobs with about the same size engine and different transmissions;-) > > PROCESSORS: > > Here I am trying to compare the relative advantages and costs of 4 processors > each configured with 64 Mb with about 1Gb disc and NAS software: > > 1. VAX 4100. 30K pounds, the most expensive. 100 point cluster rating, the > highest. What advantages does it have over the rest? Has DSSI, supports Q-Bus the 4105 has an extra DSSI bus on it. Has a Higher TPS rating than the 3100/90 because of the faster DSSI I/O. The Q-Bus also supports FDDI as an OpenVMS cluster path. > > 2. MicroVAX 3100/90. 19K pounds. 20 point cluster rating. Same VUPs as 4100. > Lacks DSSI but everything seems to be going SCSI these days anyhow... there's > no DSSI on Alpha. What do you lose by saving 11K pounds? > Lower speed I/O / Lower TPS rating, Same CPU as the 4100 otherwise but again... Can't be clustered except over Ethernet... It will perform less well on I/O intensive tasks than the 4100. You'll also have to add OpenVMS user licenses to this CPU, the 4100 seems to come packaged with user licenses. AXP supports DSSI on the new $26,000 DEC 2100... It's by no means dead... No FDDI devices for this 3000/90. > 3. VAXstation 4000/90. 19K pounds. 10 point cluster rating. Seems to be more > like a 3100/90 than a 4000, not sure of VUP rating. With lower points > rating and 19" monitor included it seems better value than a MV3100/90. I > assume you can add multiple OpenVMS user licenses. Is this the "best" VAX > choice? > The VS4000/90A is currently 38 specmarks/32-38VUPS, faster CPU than either the 4100/4105/3100-90 but with less I/O (it was designed to be a single user system after all. No DSSI available Two Syncronous SCSI busses (one internal/one external) (4Mbytes/second Each) for a total of 14 devices) Again less I/O, lower sustained TPS rating. Yes OpenVMS user licenses are available for it but by the time you finish, it might be more advantageous to buy a packaged 4105 with all the licenses bundled... Turbochannel FDDI clustering is available. > 4. Alpha DEC 3000-600 AXP. 17K pounds. Seems to equate in cost to a 50 point > cluster rating. Is the cheapest and _appears_ to be the fastest but how do you > compare it with VAX processors? Discs (SCSI only) have to be shared with other > nodes across Ethernet, does this prohibit efficient common cluster system discs? Fast SCSI-2 Only(10Mbytes/Second Each) 1 internal 1 external, CPU performance is about 156Specmarks (120-156VUPs) Unless you're CPU bound, I/O performance will be about the same as the VS4000-90 (unless you're running above 4Mbytes/Second in which case teh DEC 3000-600 will do better). Unless you add the additional turbochannel SCSI-2 channels and populate them -- With two additional Fast SCSI-2s on the 3000-600 you can get as much as 40Mbytes/Sec of I/O Throughput If you're considering several machines.. consider using a small FDDI concentrator as a MACHINE TO MACHINE interconnect and getting the cluster traffic off the Ethernet. > Is the integration of Alpha with VAX or the migration to Alpha as easy as DEC > imply? With OpenVMS 6.1, both OpenVMS VAX and OpenVMS AXP have the same functionality. VMScluster interoperablity is consistant between both hardwares, if you can use Alpha (because software is available) I suggest you do so. > > TIA > > Ken > _____________________________________________________________________________ > Ken Harris | Basingstoke UK | 0256-24737 | ken@kestrel.demon.co.uk +-----------------+--------------------------------------------------------+ | John Wisniewski | Consultant/DFW DECUS LUG Counterpart | | +-+-+-+-+-+-+-+ | Voice: 214-404-6412 | | |d|i|g|i|t|a|l| | UUCP: wisniewski@fallout.lonestar.org (DFWLUG BBS)| | +-+-+-+-+-+-+-+ | At Work: wisniewski@dpdmai.enet.dec.com | | Dallas, TX USA | | +-----------------+--------------------------------------------------------+ You're in a Maze of Twisty Little Unix varients -- All different.