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.