Sorry for the delay in getting this posted. My original query asked
for user experiences and reccommendations regarding the AlphaServer
1000 4/200.
Thanks to all who responded (individual responses are included below):
SEB_at_LNS62.LNS.CORNELL.EDU
sanghvi_at_proto.wilm.ge.com
prand_at_paul.spu.edu
carole_at_callutheran.edu
jim_at_orac.ecc.tased.edu.au
risler_at_cgmvax.cgm.cnrs-gi
weiler_at_sccs.swarthmore.edu
The most frequent suggestion was to insure that we have sufficient
memory.
Phil Rand provided the most information for us. His experience
indicates that his system is stressed at about 150 concurrent
users. However, he is using a model 3000/600, for comparison, here are
the numbers:
3000/600 1000 4/200
-------- ----------
SPECint92 114.1 135.8
SPECfp92 162.1 177.0
SPECrate_int92 2,722 3,136
SPECrate_fp92 3,857 4,230
LINPACK 1K x 1K MFLOPS 129.7 147.4
I received two requests for further assistance, please see their full
queries below, but here (with apologies) is a short form of their
question:
1. From risler_at_cgmvax.cgm.cnrs-gif.fr, he asked me if they should be
exploring a 2100 as opposed to a 1000. I'm sure he would appreciate
any assistance from anyone who has a similar environment.
2. From weiler_at_sccs.swarthmore.edu a request for information about if
they might want to use a AlphaServer for logins or as a WWW server.
-- bob
------------------------------------------------------------------------
From: Selden E Ball Jr <SEB_at_LNS62.LNS.CORNELL.EDU>
Subject: Re: Information on AlphaServer 1000 4/200
To: benites_at_cs.unca.edu
Just a quick comment. We don't have as diverse a user community here
in our lab, but we divide the server functionalities over multiple
systems. That way when one is down the others aren't impacted.
Also, Alphas require about 4 times as much memory as a VAX when
running comparable software.
Don't forget that most of the system administrative utilities that
you're used to under VMS simply don't exist under Unix. As a side
effect, more manhours are needed to provide the same functionality to
the user community. There is no integral batch system, for example.
We use DQS (freeware) on our OSF/1 systems.
I hope this helps a little.
Selden
------------------------------------------------------------------------
From: sanghvi_at_proto.wilm.ge.com (arun sanghvi)
Subject: Re: Information on AlphaServer 1000 4/200
To: benites_at_cs.unca.edu
Date: Tue, 14 Mar 1995 13:38:46 -0500 (EST)
Bob,
Few suggestions:
1. Look in to ALpha 2100 with atleast 2 cpu.
2. Raid array
3. Atleast 192mb.
4. Trade-in vms system for break on license cost.
5. Stay away from DECNet on Alpha osf 3.0.
6. Go to OSF training classes.
This is based on our recent experience in migrating from
Ultrix 4.0 on 5000/240 to OSF 3.0
Arun Sanghvi
GE-NF&CM
Wilmington, NC
------------------------------------------------------------------------
Date: Tue, 14 Mar 1995 11:38:11 -0800 (PST)
From: Phil Rand <prand_at_paul.spu.edu>
To: benites_at_cs.unca.edu
Subject: Re: Information on AlphaServer 1000 4/200
On Tue, 14 Mar 1995 benites_at_cs.unca.edu wrote:
> UNC Asheville is a liberal arts university currently supporting a
> diverse user community (students, faculty, and staff) with a VAX
> 4000/300 system running VMS. This system is stressed out right now and
> we are contemplating the AlphaServer 1000 4/200 running OSF/1 as an
> alternative to support many of the users and applications currently
> running on the VAX 4000/300 under VMS.
Short answer: It's not magic, but an AlphaServer should be a dramatic
improvement over a VAX 4000/300.
We've been using an AXP 3000/600 as our main campus time-sharing machine
for just about a year, now, and we're very pleased with it. I don't know
much about the AlphaServer 1000 4/200, but it should be in the same
general range of performance as our machine. Does the "4" mean 4
processors, or does the 200 mean 2? If so it might be quite a bit faster
than our single-processor machine, in raw CPU power.
The 3000/600's single cpu is a 175Mhz 21064. I don't remember what the
1000 4/200 uses. As I understand it, the 3000 line has a faster
CPU-memory interconnect, faster memory, larger secondary cache, greater
total memory capacity than the 1000 4/200, but its turbochannel bus is
somewhat slower than the 1000's PCI bus. On the other hand, your disk
controller and network cards may be stuck on the EISA bus, which is slower
than the turbochannel. Better ask DEC if you want comparisons less vague
than this.
> Our Computer Science Department already has some Alpha 3000
> workstations which, for the most part, they are pleased with.
Remember that, for workstations, the video subsystems are crucial to
performance, but don't matter at all for character-cell terminal users.
I'm not really into workstations, but I understand that DEC's tend to
make up for their average video performance with their outstanding CPU
power. So if your comp sci folks bought cheaper DEC workstations, that
may explain their lack of glowing enthusiasm.
> The system will be used to run character based applications,
> predominately: pine/pico for email, tin for news, lynx for WWW access,
> ftp, and telnet. There would be little, if any, X applications save
> for the console in the beginning.
Sounds almost identical to what we're doing, except we're also
experimenting with TIA, a program that provides SLIP connections via
timesharing terminal connections.
You don't mention how your terminals will be connected. We have a lot of
LAT connections, but are moving as fast as we can to TCP/IP, largly via
WinQVT/net on pc's connected to our campus network, but we also have
terminal servers in all our dorms, which we hope to move from LAT to
TCP/IP before too much longer.
> We would also be running several servers: httpd, gopherd and the
> Qualcomm pop server. We'll also be running majordomo.
We have a dedicated AXP 3000/800 for server functions, to try to off-load
the timesharing machine. You still need an httpd on the timesharing
machine if you want to let users create home pages there. Oh, and we're
running "ListProc" instead of Majordomo, and a pop3 server that is more
compatible with the IMAP protocol that pine wants than pop.
> We would like to gradually migrate our user community to OSF/1 but are
> concerned with the number of concurrent users we'd be able to
> support. I read some marketing materials where Digital indicates that
> the AlphaServer is the "top-of-the-line and suits the needs of a
> ... higher education institution that requires high availability and
> room to grow." Naturally, this sounds like your typical marketing
> hype.
We have somewhere around 2500 accounts, and as many as 150 concurrent
users at peak periods. Performance is pretty good up to around 100 users.
Much beyond that, and you begin to notice it. I'd say it's acceptable up
to 120-130. By 150, it's really annoying. Also, OSF/1 (we're still
running 2.1 -- you'd probably start out with 3.0 or higher) is a much less
mature operating system than VMS. When you stess it, it's a lot more apt
to run into trouble. Remember what VMS was like back about V3.5, or so?
Every once in a while it would crash for no apparent reason? Well OSF/1
is still in that stage. Most of the time it works great, but you have to
expect an occasional glitch if you stress it like we do.
I'm not blaming DEC for this, at least not too much. We don't have any
REAL Unix experts, so we tend to shoot ourselves in the foot once in a
while. For example, I suspect we're in need of more memory, (192 megs
currently), but I don't yet have the skills to prove that in a
professional way. When the current level of performance becomes enough of
a pain for my managment to make it a high priority, I'll drop everything
else and study up on OSF/1 performance management for a couple of weeks,
and maybe come up with a clear recommendation of just how to throw some
money at the problem. Don't underestimate the problems you'll run into if
you can't afford to invest in training for your system administrators.
But even if you're in the same boat as us, with sysadmins initially only
knowing VMS and having neither time nor budget for formal training, if
you're willing to accept an occaisional glitch, you'll do ok. Unix system
management uses all the same principles as VMS system management, so the
folks who've been running your VMS systems already have the right
attitudes for running Unix. It's just a matter a learning a bunch of new
tools. (You DO have dedicated system administrators, don't you? If not,
forget this whole idea, or plan to hire an outside site mangement firm.)
> What I'd really appreciate is some feedback from institutions that
> have an AlphaServer running some (or all) of the above
> applications. I'd also be interested to know how many concurrent users
> you service comfortably, and at what point response time becomes
> unacceptable. I'd like to hear of other application software you found
> to be very popular, if any.
>
> I'd also be very interested in any suggestions, "gotchas" to watch out
> for, supplementary hardware that people found essential/desireable,
> problems, horror stories, and of course, satisfied customer
> testimonials.
Be sure not to skimp on memory. Remember that the VAX was designed when
memory was expensive, so it's quite memory efficient. RISC machines trade
off memory efficiency for speed, and the Alpha is one of the RISCiest RISC
designs around. If your load was going to stay the same, I'd recommend a
bare minimum of twice as much memory on the Alpha as was comfortable on
the VAX. Since your load isn't going to go anywhere but up, get as much
memory as you can possibly afford. Consider buying memory instead of a
2nd or 3rd processor chip.
> Our environment has multiple hardware and software platforms, so I'd
> also be interested to know about interoperability problems or success
> stories.
We're blessed with an all-DEC shop, as far as Unix and VMS boxes go. We
do have several Windows-NT servers (mostly pentiums, no Alphas), and
hundreds of Windows for Workgroups pc's. No interoperability problems to
report.
We used to have Pathworks, but are kicking it out in favor of Windows for
Workgroups and NT servers. It's too expensive, and too much of a pain to
get working right. Too bad, as it used to be a good product. From now
on, we'll use standard tcp/ip tools like telnet and ftp for pc to unix or
pc to VMS interoperation. Works great.
-- Phil
--
-- Phil Rand prand_at_spu.edu
-- http://paul.spu.edu/~prand/
-- Computer & Information Systems (206) 281-2428
-- Seattle Pacific University, 3307 3rd Ave W, Seattle, WA 98119
--
-- SPU People: For a lively SPU-specific discussion of computers, our
-- campus network, email, exploring the Internet, etc., send an email
-- message to listproc_at_spu.edu. Put this line in the message body:
-- subscribe SPUnet-L Firstname Lastname
------------------------------------------------------------------------
Date: Tue, 14 Mar 1995 14:23:34 -0800 (PST)
From: Carole Thompson <carole_at_callutheran.edu>
To: benites_at_cs.unca.edu
Subject: Re: Information on AlphaServer 1000 4/200
We are running an Alpha 2000/300, OSF/1 3.0b. Normally, our concurrent
user load runs at 30+ (out of 1400) accounts. I was just at a conference
where the estimate was: plan on 1.2 mb of RAM per session; we now have
128mb of RAM and (knock on wood) no system degredation. We run the
applications you mentioned, but no X... at all, and tin as soon as I
compile (could you send me your Makefile for the sake of comparison?)
Feel free to ask me other questions.
Carole Thompson
carole_at_callutheran.edu
Information Systems and Services
California Lutheran University
(805) 493-3944
------------------------------------------------------------------------
To: benites_at_cs.unca.edu
Subject: Re: Information on AlphaServer 1000 4/200
Date: Wed, 15 Mar 95 13:13:38 +1100
From: jim_at_orac.ecc.tased.edu.au
This a brief response. Feel free to quiz me more.
We have a statewide library system. We currently run 450 users and
expect to run 700-800 users. It's a 4720 (2 cpu's) with 768Mb of RAM
and 48Gb of disk. Response time is excellent. Unplanned downtime has
been of the order of 6 hours in the last 12 months. Three of those
hours was my fault and a further 30 min was due to a power failure.
We mirror most drives using LSM and run the Advanced File System (I highly
recommend this product!!!)
Jim.
______________________________________________________________________________
Jim Palfreyman Information Technology Branch _--_|\
jim_at_orac.ecc.tased.edu.au 2nd Floor 73 Murray Street / \
phone: +61 02 336900 Hobart \_.--._/
fax: +61 02 336969 TAS 7000 Australia v <-- I be 'ere
______________________________________________________________________________
------------------------------------------------------------------------
From: risler_at_cgmvax.cgm.cnrs-gif.fr
Date: 14 Mar 95 18:24:30+0000
To: alpha-osf-managers_at_ornl.gov
Subject: Infos on alpha servers
In a recent posting, <benites_at_cs.unca.edu> asked for infos about the
various alpha servers.
I was just about to post the same request ...
Here we are a biology lab (might not be your cup of tea...). Our main
applications deal with the scanning of "sequence databanks", for
example to find whether my recently determined sequence looks like
another sequence already in the databank. For the time being, the
databanks are flat files of several Moctects. These applications are
rather I/O hungry. Some other programs, however, use much more CPU.
For the moment we run a Vax 6300 under VMS. We want to move to Unix,
and intend to buy an Alpha platform.
On the average, we have 15-20 simultaneous users -not necessarily all
very active.
My question is: would you think that an Alphaserver 1000 would be
sufficient, or should we consider an Alphaserver 2100 ? Of course, we
would prefer the cheapest solution, but paying less for getting a
saturated machine would not be a good option...
Thank you for your help,
Jean-Loup
---------------------------------------------------------------------
Jean-Loup Risler Tel: (33 1) 69 82 31 34
CNRS Fax: (33 1) 69 07 49 73
Centre de Genetique Moleculaire Email: risler_at_cgmvax.cgm.cnrs-gif.fr
91198 Gif sur Yvette Cedex France
---------------------------------------------------------------------
------------------------------------------------------------------------
From: Samuel Weiler <weiler_at_sccs.swarthmore.edu>
To: benites_at_cs.unca.edu, weiler_at_sccs.swarthmore.edu
Subject: Re: Information on AlphaServer 1000 4/200
X-Newsreader: TIN [version 1.2 PL2]
On alpha-osf-managers you wrote:
: UNC Asheville is a liberal arts university currently supporting a
: diverse user community (students, faculty, and staff) with a VAX
: 4000/300 system running VMS. This system is stressed out right now and
: we are contemplating the AlphaServer 1000 4/200 running OSF/1 as an
: alternative to support many of the users and applications currently
: running on the VAX 4000/300 under VMS.
I would appreciate a summary of any responses you get. Swarthmore
College has a student run system supporting about 300 regular users of
services similar to what you mention on a DECstation 5000/200.
Increasing WWW traffic has caused our one machine to very nearly die,
and we're looking at purchasing an DEC 3000/400 AXP.
The uncertainty is whether to use the Alpha for general logins or for
the web server. We eould like to provide the best possibe service for
on-campus general access users, at the expense of the web server, but
we have no real information on how the Alphas perform with multiple
users.
--
Samuel Weiler <weiler_at_sccs.swarthmore.edu>
Received on Fri Mar 24 1995 - 11:54:21 NZST