knechod%peruvian.utah.edu@cs.utah.edu (Kevin Nechodom) (06/13/91)
After long last, here is the summary of responses to my plea for help.
I apologize for my lousy job of editing, I don't know what I'm doing!
Well, on with the show ...
From jinx@altdorf.ai.mit.edu Tue Jun 4 17:42:01 1991
Binary compatibility is irrelevant with X terminals, since all the
programs will run off the server. Performance will downgrade on a big
run, but I'm very impressed by the 700s. Admittedly I haven't used
SS2s, but we have two 720s and not only is their CPU fast, but the
rest of the system, including IO seems very fast as well.
If you get the differential SCSI upgrade and disk for the 730, you may
very well get better IO out of the HP. Given the standard benchmarks,
I would not be surprised if the 730 could easily keep up with the SS2
even when loaded.
HP has a nice solution for handling different binaries on diskless
nodes. Their cluster software is reasonably good, and should work
well between a 700 and some 400s. Of course, by having different
architectures, you will have to have two copies of all the binaries.
If the software is homebrew, the only problem is disk space. If you
have to buy the software, you may have to pay for two copies.
A third possibility, if you find that performace with the X terminals
is not so great, is to get some cheaper Snakes. There is a rumour
going around (which I have reason to believe) that HP will announce a
720 performance Snake in October for under $10K.
From schultz@halley.serc.3m.com Tue Jun 4 21:45:40 1991
As a point of reference, a local HP OEM sells HP 1.3 GB (unformatted)
disks under their own label for well under $3000 per disk. DataLink in the 612
area code.
I have Sun telling me that X-terminals are not good for a development
environment, and that binary compatibility between all workstations is a
Good Thing. Hanging X-terminals will degrade performance for
everyone on a big run, while a separate workstation will not.
BS - if the big run is cpu or disk IO intensive, why would the X terminal
care? There are not many applications which are display bound. However, I
personnally like to have local compute power because software is starting to
be able to be distributed across a network to take advantage of unused
computer power, even across hetergenous environments. (Refer to a recent
announcment of CONDOR from Univ of Wisc. Madison.)
Trying to maintain a hetergenous (Sun 3, Sun 4, HP 9000/800 in may case) is a
pain in the @#$%@#. While I agree that the RISC server for a CISC machine (or
vice versa) is OK, keeping track of all the binaries and the object files is
non-trivial. That said, I am greatly in favor of maintaining a hetergenous
environment so that as one workstation vendor pulls ahead of another (HP in
mid '91), you can gracefully expand you network. I also like a couple sun 4's
in the network just because most software will run on them. With HP's
price/performance, more software will become available for them however.
With X technology, the actual compute location is somewhat irrelevant.
Qualitatively I thought that the IO on a 4/330 and a HP 720 were about the
same. I disagree that database and statistics are mostly IO bound.
Manipulating large databases and making new tables is typically compute bound.
Promote the idea of a hetergneous environment running X and NFS. This will
allow your department to gracefully add (and remove obsolete) computer power.
The only problem I see between SUN and HP workstation coorporating is that
most public domain software and much commercial software is avaiable for SUNs
before HPs.
From henry@geoph.ucalgary.ca Wed Jun 5 01:43:45 1991
We just had a 720 on loan. Yes, it ran out floating point benchmarks
quite quickly, though there were some pretty strange things happening
when we did interactive work on it. We found that login time and logout
time (with nothing fancy in login script files) was abysmal. Users who
were't aware of the SPEC rating on the HP 720 thought it was "much slower"
than our other systems on demo (SS2 and MIPS 3330). In general, it
had a "feel" of a much slower system.
You and your users might not get this impression. All I can suggest
is to get your sales people to bring in demo machines. We've had
5 vendors (IBM, Sun, SGI, MIPS and HP) all give us loaner machines
to evaluate (my office looked like mission control).
Our evaluation could be summed up as follows:
HP 720
- good on CPU intensive jobs, epecially floating point
- doesn't handle large virtual memory jobs very well
(even though there's plenty of RAM left)
- OS os "OK" though it looks a little rough yet
- X implementation needs work (not too hard to get it to crash)
Sun SS2 - very consistant reponse for interactive work
- slow floating point
- tons of public domain code runs on it
- X system lacks a lot of standard MIT stuff (no Xaw, no Xmu)
- Very stable OS
MIPS 3330
- very consistant speed
- X implementation is very fast
- X is up to date, X11 R4, Motif 1.1, comes with all the goodies
- floating point performance is OK, integer is great
- Very "clean" OS, System V is not mixed up with BSD
- BSD environment is quite complete. BSDeers can still feel at
home even though the system is not BSD.
IBM 320
- excellent floating point
- X implementation is X11 R3, Motif 1.0, very out of date
- mishmash of System V and BSD - very unpredicatable
- nothing compiles on this machine without lots of changes
- fast I/O for small data sets (lots of caching going on)
- some nice unix feature - logical volume sets (allows files
to span multiple physical disks)
SGI Personal Iris 4d/35
- haven't evaluated it yet.
I think in our case, the decision will be made on the basis of software
availablity for our application (geophysical data processing). For
that reason, we'll sadly be chosing Sun or IBM. Oh well...
Good luck,
-Henry Bland
From chris@cxbne.cx.oz.au Wed Jun 5 08:11:54 1991
Well,
my 2cents worth is if SUN can't bring themselves to support one
of the (IMHO) best advances in computing (Xterminals) and continue to try
to tell the rest of the world what computing in the 90's is
about tell them to get stuffed!
The HP's are not as fast as they are made out to be. Half of their
big spec no's are in the floating point intensive code with their
new Fortran preprocessor. However they are the fastest on the
block at the moment and if you are happy with HP and don't mind
not being a sheep go with them.
From se@ikp.Uni-Koeln.DE Wed Jun 5 10:30:00 1991
1) Its nonsense, when Sun tells you X terminals would result in low
performance because of high net load. I know of installations with
Sun workstations, that are going to switch to X terminals connected
to servers to *reduce* the netload!
(Prestoserve didn't bring the expected performance boost.)
If you are using database applications, the NFS mounted file systems
will be a much more severe bottleneck than the X transfers.
2) I wouldn't buy the HP workstations, primarily because of bad
experience with HP and HP-UX. My choice were a reasonable
workstation (eg. Sparc 2) with lots of RAM and fast disks,
connected to fast X terminals (but I'd choose Tektronix over HP!).
We use lots of Tektronix X terminals (grayscale + colour), they
perform better than Sparcstations (as X displays) under most aspects.
Performance on *one* LAN with some NFS and VAX cluster traffic,
is no problems at all. A busy X session results in about 30K/s
being transferred, that means that (without NFS) 10 to 20 X terminals
could be *very* active simultaneously without disturbing each other.
The Sparc IPC has a very poor display quality and is relatively slow
(and only black/white) compared to at least grayscale X terminals.
If you connect local swap disks to the IPCs, they will become noisy.
If you run your applications on several workstations, you can't take
advantage of code sharing or fast inter process communication.
That results in a lot of overhead and may cost more CPU cycles
than the additional workstations provide.
Once again in few words, i would buy:
1) A fast workstation (Sparc 2, DEC 5000/200 several others,
but (IMHO) not the HP 9000/7x0 or IBM RS/6000).
At least 32 MByte RAM, at least 1 GByte RAM,
EXABYTE (or DAT) for Backups
2) Tektronix X terminals (XP-21, XP-23 or XP-29-CM).
If you would like further explanations (eg. about problems with HP),
send a short note.
Stefan
--
Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany
se@IKP.Uni-Koeln.DE [134.95.192.50]
From @ois.db.toronto.edu:jdd@db.toronto.edu Wed Jun 5 11:58:48 1991
There's a certain amount of truth in the degradation claim. If one user
runs a massively big job, all the users will notice.
The binary compatibility claim is a red herring. You'll be doing all
development on the HP 730; all the 700/RXs would be used for is X. So you
really won't have to deal with multiple architectures very often.
>I have HP telling me that even loading down the server with two X-terminals
>would not bring the performance down to the SS2, and definitely not down to
>the IPC's. They have also told me that there is no big deal having a
>workstation with a CISC chip running off a RISC server, and I could put some
>of their recently announced 425's if I really wanted local workstations.
HP is absolutely correct.
Sparc floating point isn't too bad. HP 730 floating point is *very good*,
however.
I/O performance on the IPCs will be terrible, since all I/O (except
swapping/paging and /usr) would be going over the network to the fileserver.
I/O performance on the SS2 will be good.
Test the political waters very carefully. It may be that you don't have a
choice. Make sure your boss is really allowing you to make a free choice, and
isn't trying to shove a ready-made choice down your throat.
>My own biases are towards HP. We have been an HP3000 customer for over 11
>years, and I have been very happy with their machinery and support. I chuckled
>to myself about HPUX 8.05 getting shared libraries, because I have been using
>them since Day 1.
That's a fairly big point in favour of HP.
I'd go the HP route, if you don't mind their longer shipping times (check
with them to find out when your 730 would arrive), and if the maintenance
costs are comparable.
Reasons:
Both configurations have roughly the same amount of CPU power, except that
in the Sun configuration, it's divided among the various workstations. This
makes it more difficult to take advantage of unused cycles, since a job
running on one IPC can't take advantage of unused cycles on the SS2 or other
IPC. Same for memory. Finally, I/O performance will be very inconsistent
on the Sun side. On the IPCs, I/O will be poor. On the SS2, I/O will be
good. If most of your workload is I/O-intensive, you'll be wasting your
time with the IPCs.
Finally, you seem to like HP as a company, and (I presume) are comfortable
with HP/UX. HP/UX is the reason why *we* don't buy HPs; if that's not
a problem with you, go the HP route.
John
--
John DiMarco jdd@db.toronto.edu or jdd@db.utoronto.ca
University of Toronto, CSRI BITNET: jdd%db.toronto.edu@relay.cs.net
(416) 978-1683 UUCP: uunet!utai!db!jdd
From kd4nc!km4ba!alan@gatech.edu Wed Jun 5 12:48:46 1991
In comp.sys.hp you write:
>DB and stats are mostly I/O intensive, and Sun is better than HP for I/O.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
be cautious about Blanket assumptions..... Comparing disk I/O involves
many things. Some are:
buffer cache size- My understanding is that Sun's allocate
buffer cache dynamically using any free memory. HP allocates
based on a kernel parameter. Thus: Single process I/O when
you have lots of memory looks good on Suns. Heavy multi
process with less memory available will not do as well.
Bottom line- many HP boxes need to have buffer cache
increased slightly, then perform as well as Sun in this
area. I have known Sun to take advantage of this in
competitive benchmarks. (Extra memory, few processes)
HP is default configured for a conservative buffercache
to allow maximum RAM for applications.
With SIMM type cheap memory this is less of an issue.
Which HP I/O? Low speed HPIB, High Speed HPIB, DIO SCSI, DIO-II SCSI?
All have different thruput. There can be a factor of ten
difference. Snakes & new 400's use fairly fast scsi. I would
be suprised to see much difference in throughput on a properly
configured system. (See buffercache discussion)
Be cautious about quoted xfer rates from any vendor. It is
very system config dependant. Most actual sustained thruput is nowhere
near quoted "burst" rates.
HP-PA (risc) systems tend to hold up better under heavy
loadings than many workstations. The focus of many workstation
vendors has been on single/low tasking scenarios. Many benchmarks
and quoted specs reflect that. Remember HP-PA & the O/S has
been tweaked for a heavy multi user environment. (Even at the
HW cache level) Many lowend W/S product would turn in comparable
single task oriented benchmarks as bigger HP-PA products. However,
the performance "Knee" as you added processes was dramatically
different. The X term scenario involves mainly multi task cpu perf
and lan issues.
Remember snakes & 8.?? were tuned for X usage. So were the new
fast X terms. Play with them yourself. Do not let someone else's
perceptions based on 1-2 yr old X-terminal & server technology
make up your mind for you.
I am biased towards HP. (I work for HP) However, I have been involved
in benchmarks and competitive situations against Sparcs & RS/6000's
where differences became obvious. I also had some unrealistic
benchmarks that resulted in poor real world performance once
installed. (IE: HP was not selected the first time , but was brought
in later to replace the vendor who "won" the benchmarks.)
Now, snakes perform well in both scenarios. (Fast graphics/X as
well as decent multi user performance.)
If snakes were the first HP-PA system on the market, I would be
much more cautious. However, the main complaint about previous
HP-PA systems was cost. That has been resolved with the snakes.
But don't take my word for it, go try it out. Lay your hands on a
config like what you are looking for, and kick off some compiles.
My rule:
Believe none of what you hear, and only half of what you see!
Good Luck!!!
Alan Barrow km4ba | I've seen things you people wouldn't believe. Attack
jab@hpuerca.hp.com | ships on fire off the shoulder of Orion. I watched
| C-beams glitter in the dark near the Tannhauser gate.
..!gatech!kd4nc! | All those moments will be lost in time -
km4ba!alan | like tears in rain. Time to die. Roy Batty
From jmr@Princeton.EDU Wed Jun 5 13:07:47 1991
From: James M. Roberts <jmr@Princeton.EDU>
I manage the computers for the CS department at Princeton. Recently
I ordered a HP 730 for my desk.
Being a long time Sun user, I understand some of your dilemna.
I used to dislike X-terminals, probably because Sun has a bias
against them. With some X-terminal experience behind me, however,
I prefer them, because I can move a user from one architecture to
another and not have to change their monitor and keyboard.
We run 70-80 X-terminals on our network, supported by a couple
of DECstation 5000s (sort of Spark 2 equivalent), and I must say
the X-terminals do very well.
SAS on HP is far superior to SAS on a Sun. SAS has recently
announced that they will port to HP before Sun, because they prefer
the HP environment. The floating point will be MUCH faster.
The throughput on the HP, from the viewpoint of X traffic or
the ethernet, is much higher than the Sun. (I suppose it might
depend on which model HP you are ordering ...)
It's true that having local disks, everyone person having his
own sun, is faster than going over a net, but the management
hassle is also much greater.
To support our 70-80 X-terminals, we have one /usr partition -
which also supports about a dozen workstations. We have
different /usr/local partitions for different architectures.
Good luck on your choice!
jmr@cs.princeton.edu
From @stl.stc.co.uk:ag@crosfield.co.uk Wed Jun 5 14:15:21 1991
From: "Andrew R. Gray" <ag@crosfield.co.uk>
In article <1991Jun4.164957.10585@hellgate.utah.edu> you write:
Having worked with both HP and Sun kit over the last 8 years I tend to
agree with your HP/X-Terminal solution. I've recently setup two X-terminals
( 3/50's running X-kernel actually ) hosted from a Sparcstation-1+, which
also supports two other diskless Sparc1's. The performance of the X
terminals is in the same league as the diskless sparc's, and the server
isn't noticably affected by the X support - I haven't analysed the stats
yet by my feeling is that the server ( which is on my desk, so I'd notice !
) is actually responding better than when the two 3/50's were setup as
diskless systems off of it.
Your database to my mind is another nail in the coffin of the Sun approach.
You don't say whether you propose using a database with proper network
support ( E.g sybase ) or running it via NFS. If you're thinking of NFS can
I advise you strongly against it - I have never seen a database that works
properly ( I.E decent response times ) over NFS. The X-terminal approach
effectively gives you another bitmapped display onto your HP-730 so the
problem never arises. This incidently might prove to be a significant cost
saving - you only need a single CPU licence for your database software.
Clearly Sun have a point as regards heavy number crunching loading the CPU
on the HP and in this respect X is a lot more resource hungry than NFS. I
wouldn't worry too much about it though, in my opinion the X load is
directly proportional to the computing ability of the user - only
"power-users" will create a problem. Its sounds to me as though your Sun
salesman is getting desperate !
On the relative reliabilty of the two camps, I personally place HP several
streets ahead of Sun. The only time I have actually seen a HP machine fail
was in a poorly ventilated factory environment - all the PCB's had obtained
a nice thick coating of highly conductive carbon black ! On our network of
100+ Sun's there is usually at least one hardware failure a week. The same
line of reasoning applies to disks - HP are generally reckoned to the one
of the best in the world.
As regards to compatiblity & 'co-operation' you should bear in mind that
the next version of SunOS is actually System-V release 4 which will take
Sun significantly closer to HP at and operating system level. I believe
this is scheduled for release at the end of this year.
I think your decision is really whether to go 'X' or multiple workstations
- both vendors now have good products for both options. The best solution
depends on the balance you'll have between number crunching and database
I/O. I'd be interested to know what conclusion you finally come to.
Andrew R. Gray, uucp: ag@cel.uucp -or-
Senior systems support engineer, ag@crosfield.co.uk -or-
Crosfield Electronics, ...!{mcsun,ukc,uunet}!cel!ag
Three cherry trees lane,
Hemel Hempstead, phone: +44 442 230000 ext 3850
Herts HP2 7RH fax: +44 442 232301
England. telex: 827530 CROSEL G
From @ois.db.toronto.edu:jdd@db.toronto.edu Wed Jun 5 14:44:34 1991
From: jdd@db.toronto.edu
Actually, we had an HP 720 here for demonstration purposes, and found it
a very attractive piece of hardware. However, software was a little unstable,
and HP/UX was a little difficult for us to live with, given our heavy
dependance on BSD-derived stuff. Most of us decided to stick with Sun,
but I have a warm spot in my heart for any company that can design a
workstation as fast and as inexpensive as the HP 720/730.
John
--
John DiMarco jdd@db.toronto.edu or jdd@db.utoronto.ca
University of Toronto, CSRI BITNET: jdd%db.toronto.edu@relay.cs.net
(416) 978-1683 UUCP: uunet!utai!db!jdd
From KRATZ@BNR.CA Thu Jun 6 06:31:17 1991
From: Geoffrey Kratz <KRATZ@BNR.CA> (G.)
In article <3731@brchh104.bnr.ca> you write:
>HELP!!!
Well, I can try :-).
>I have Sun telling me that X-terminals are not good for a development
>environment, and that binary compatibility between all workstations is a
>Good Thing. Hanging X-terminals will degrade performance for everyone on a big
>run, while a separate workstation will not.
This depends on the nature of the work you are doing. X-terminals are
a good thing when you *have* to have multiple people on one
workstation, because it gets the X server off of the host machine. As
well, X-terminals can ease the system admin load, since you are only
taking care of one machine.
There is a non-obvious down-side to X-terminals: network traffic. If
you have badly behaved X applications, then you could end up with a
clogged network (and there are more badly behaved X applications than
you might think).
However, if you need the compute power for every user, and the compute
server for the X-terminals isn't enough, then you will have to resort
of having a workstation on every desk.
The question to ask: what are the users/developers doing in
particular? What is their work pattern? How big are their jobs? I
would recommend getting demo units for both the HP and Sun
configuration and testing them for speed. If the jobs are big, then
you will likely want to go with a workstation on every desk. If the
jobs are smaller, then sharing a machine between users would be one
way to go.
Having two different platforms isn't too bad. Having three will start
to make things tricky, mainly because the 700's and 400's use slightly
different OS's (even though they have the same name and version), and
this will be painful. So, if you're going to revert to local
workstations, why make life any tougher than it has to be?
Putting 2 X-terminals on a 700 would likely drag it down a fair bit.
As you mention further on, I/O on HP's is rather abysmal. Combine
that with a pretty simple-minded paging scheme means you spend a lot
of time waiting for the disk to spin. I would really recommend
against putting more than 1 or 2 people on a 700 series (and no more
than 1 on a 400). We put 2 on 9000/300's and 9000/400's now, and its
pretty bad for performance, but most of the bottleneck is in the I/O,
not the processor.
Yes, databases are I/O intensive. In this case, the Sun's are likely
to be faster than the HP's. HP still hasn't got their SCSI drivers
right, and so they typically get sub-megabyte per second performance
to their disks. Suns will get at least 3, and as much as 6 (depending
on the disks).
Stats, though, are likely to be FP intensive. The floating point on
Suns is pretty bad, but you can get S-bus cards to improve that.
Check any issue of SunExpert, UNIX Today! or UNIX World for ads.
>My boss would like a good level of cooperation within the department, and it
>seems that buying Sun would do that.
It is something worth considering. Having all the machines the same means:
- when things break, you know who to call and who's at fault, and don't
have to go through finger-pointer exercises
- you don't have to train people on two very different environments (and
tear your hair out trying to keep them straight when you use them)
- you don't have to worry too much about "portability" (neither is
truly System V, POSIX or XPG, despite their claims. They're close,
but not quite)
Our experience is their 3000 support and development is different from
their 9000 support and development. Our parent corporation (NT) has
used 3000's for some time now, and has received excellent products and
support for them. Our corporation (BNR) is largely 9000/300's and
9000/400's (about 1500 of them), and the products and support are
average (ie: if you're used to typical workstation support, then
they're about as good/bad as Sun; but support for UNIX workstations is
currently pretty bad). HP is big enough that each "division" is
somewhat unique, and I wouldn't judge the entire company's performance
based on dealing with just one of small part.
I don't know if this has helped. We deal with this sort of problem
every day (my department consists of Suns, HP's, Macs and X-terminal
users), and have yet to come up with a magic formula. If you can,
get in demo units and test them. It's easier than "guessing" and
hope that you don't guess wrong.
Regards,
Geoff
--
Geoff Kratz Bell-Northern Research, Ltd. kratz@bnr.ca
(OSI) Open Systems Ottawa Ontario Canada
From auvsaff@auvsun1.tamu.edu Thu Jun 6 07:30:03 1991
From: auvsaff@auvsun1.tamu.edu (David Safford)
I just recently evaluated configurations very similar to both
of the options you mentioned - CPU server with 2 X terminals
vs Disk server with 2 diskfull Sparcstation clients.
There is no clear winner - both have advantages and disadvantages.
CPU + 2 X terminals:
Advantages:
- rapid logon (don't have to wait for X11 startup!)
- fast graphics (CPU is not tied up with drawing)
- large applications/data do not have to be NFSed
to clients, so apps start faster.
Disadvantages:
- one large CPU job will drastically affect ALL user's
visible response times, as they all share the
one CPU.
Sun server + 2 diskfull SS:
Advantages:
- each user gets a dedicated CPU (other users cannot hog it!)
- greater total CPU throughput (3 CPU, 3 disks)
- greater disk/memory expandability
- can do true client-server database
Disadvantages:
- slower startup of apps (if loaded across net)
- slower logon (have to start up X11)
- graphics competes with local CPU
Comments:
1) Don't believe any vendor benchmarks. Period.
Specmarks are reasonably valid for what they measure,
but they are terrible predictors for many applications,
particularly database. IBM claims 2-4 times better
performance for its RS/6000 compared to the equivalent
Suns. My own benchmarks, and independent database TPS
(transaction per second) benchmarks, show the Suns to
be equal to or faster than the IBM! I have no
comparable data for HP, but don't blindly believe their
claims that one HP > 3 suns -- I don't believe it for
a second. MIPS are meaningless
2) The real tradeoff will be in the nature or your application.
If it involves NFS access to large data files, the Sun
clients will lose. If it is integer CPU intensive, the
Xterminal version will have problems.
dave safford
system engineer
department of computer science
Texas A&M University
auvsaff@auvsun1.tamu.edu
From: IN%"broadley@schneider3.lrdc.pitt.edu" 5-JUN-1991 13:08:08.87
How did Sun substantiate the idea that the Sun is better than HP at I/O
Sun told me lots of things that they had that were better, that either
didn't apply to me or were very hard to substantiate.
As far as my prices went the Sparc II wasn't much cheaper than
the 730, and was half as fast.
Is the Sun grey scale? The HP is, even in text applications
sometimes it real nice to have a few shades of grey instead of dithering.
What percentage of time do you expect users to be running mail, editing,
other things besides running the DB?
How are the IPC going to get to this large DB? Are they going
to sequentially access the total DB over the net?
The xterms will only have to transmit what goes to the screen over the net.
When only one person is doing something intensive he will get
75 MIPS, how much will he get on a IPC, especially after moving large
files over the net, or were you going to have 3 copies around.
Sun claims to make better use of available RAM, when pressed
they could give no details.
I making an evaluation HP was much mroe supportive than Sun.
You also might want to look at tektronics for xterms, they are
very eager, and ready to deal.
-Bill
Broadley@schneider3.lrdc.pitt.edu
From: Mikael Johansson CRC <mikaelj@hpustoa.hp.com>
Hi,
Let Me first tell You that I'll try to be objective even if my home is HP.
I have worked for Sun as well and I have some knowledge about their systems
as well.
X-terminals are a burden for the server but the amount of X-terminals You
have configured Your system with should be a piece of cake for a 730.
I'm not sure about how You are going to have the Suns configured (discless,
dataless or fullblown standalones) but the access over the network from
the SS2 fileserver will degrade the overall performance especially on the
IPC:s and the SS2 has to take care of the NFS-service which is a burden.
Pls. consider the advantage of a singlepoint administration and ease of
taking care of one system instead of three.If You are planning to have the
IPC:s diskless,I can tell You that discless over NFS is SLOOOOWWWW.
X-terminals together with a fast server like the 730 is a clean and easy-
to-use system.
The tests and the presentations We have seen on a 720 and two X-terminals has
shown equal or better performance than a SS2.If I were You,I would let both
us and Sun demo the performance.The 730 can be used to serve discless 425e:s
and the discless performance is much better on a HP cluster than it is on a
Sun cluster.
You can also make the decision to use X-terminals now and upgrade to worksta-
tions later and the plans for HP is to add lower-cost models of the 700-family
in a not so distant future. The price/performance would most likely be out-
standing on these workstations and they will be binary-compatible with the
730 if that's something You are worried about.
First of all SAS Institute have signed an order to use the 700-series as the
development-platform of the SAS-package.Sun has a dynamically growing file-
system-buffers which can speed up the I/O especially during benchmarks when
nothing else is running in the system.I have heard that we are considering
implementing this as well.The new EISA SCSI-2 adapter and the new fast discs
seems like a good deal.The UnixReview May 91 has a test of the 720 and I recom-
mend that You buy a copy or try to loan a copy.The disk-test says and this is
a quote:
"The results for the 9000/720 are among the very best disk performance results
We have seen to date"
There is also figures comparing the 720 to SS2 and it looks very good.
If You can't get a copy send Me a mail with Your fax# and I'll fax a copy of
the test to You.
>
> My boss would like a good level of cooperation within the department, and it
> seems that buying Sun would do that.
>
It's a very good point and the HP:s are going to co-exist as well as it can
without being able to run SPARC-binaries.
If the HP3000 is at the site You are working at right now it's nice to know
that the terminal-windows under X11 on HP:s can be run as HP-terminals doing
block-mode and all.
I use that to some internal systems and it works great.
>
> What a quandrary! What am I missing? I'm running a 2 minute drill here, but
> I hate making snap decisions! I am open to any and all comments (notice the
> cross-posting).
>
I feel for You.It's not easy to make the right decision but I think that going
with HP would be at least as good as any.I hope I have given You some input
without the normal sale-talk.I'm sure that You can take it from here and it
would be great to continue to have You as a customer.
Best Regards and good luck,
---------------------------------------------------------------------------
Mikael Johansson
Hewlett-Packard Sweden
mikaelj@hpustoa.hp.com ____
.-~-. / \
_ ___o``\___________/ IBM \______/ Sun \___________________________
/ \ V````\ @ @ . .. .. .- .. . .. .- .. .. .- _ .. -. ..--
(DEC) /.------------\___/--------\____/------------------------
\_/ >--_// HP Apollo 9000 series 700. Setting the pace in RISC-based
`' workstation performance.
From ajayshah%alhena.usc.edu@usc.edu Thu Jun 6 12:20:31 1991
From: ajayshah%alhena.usc.edu@usc.edu (Ajay Shah)
My 2c worth:
- Suns are indeed good on IO and weak on FP. But the
HP spec-benchmarks lie. They have strange instructions
oriented towards one of the SPECs and they have a
fortran preprocessor which everyone will have soon enough.
The performance seen is a combination of a basically good
machine, one tweaked machine instruction and a good
preprocessor idea. Of these the 1st is good, the 2nd is
not and the 3rd will appear at the competition in no time.
- HP doesn't have a good reputation in Silicon Valley as
being a fast company. I would not bet on their ability to
keep up with Sun over the next two years or so.
A new chipset (by Sun) being announced at HotChips 3 is
a real breakthrough. It took a while coming about, but
it's good stuff.
Yes, I think binary compatibility matters. I've got
screwed porting simple things like shell scripts in life!
--
_______________________________________________________________________________
Ajay Shah, (213)734-3930, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________
From bt@inmic.se Thu Jun 6 16:51:45 1991
From: Bo Thide <bt@inmic.se>
All the (HP *and* independent) benchmark comparisons between HP9000/700
and Sun SS2 I have seen show very clearly that HP is MUCH faster on
all types of I/O. What are your data points?
Bo
bt@irfu.se
From se@ikp.Uni-Koeln.DE Thu Jun 6 20:38:02 1991
From: se@ikp.Uni-Koeln.DE (Stefan Esser)
>From your first message I know, that you are a satisfied HP customer.
We got our HP 9000/835 more than two years ago, and while it was a
fast machine (at that time) we soon noticed performance problems.
It took some time until I found the reason in the extremely slow HP-IB
drives and the kernel not being adapted to them. And now comes the real
problem: While HP-UX is derived from BSD 4.3 (which I highly prefer over
AT&T System V.3) HP made it look like a System V.2 system. That means,
they took away all the capabilities and features not part of System V.2.
(Well, not really, networking and the option to choose the BSD file system
remained.)
One example:
The kernel is BSD, but you can't tune it the way its possible in BSD,
because some parameters are hardcoded (with wrong values) into the kernel.
The result is, that when there are several large applications (with the
C compiler growing up to more than 30 MByte being one of them), the system
tries to free some RAM by paging. But our I/O system's throughput is limited
to 350 KByte (the max. I ever watched on the HP-IB). The system starts paging
when there is nearly no free RAM left, but its to slow to free a reasonable
amount of memory within few seconds. That is when the kernel decides the
system to be overloaded and starts swapping. But that makes everything worse,
because the problem already came from to much disc activity !
In the end the system swaps ALL processes. I can watch the system page in
some at a low rate. The kernel doesn't page in the processes fast enough.
Although there is only 1 Mbyte of RAM in use and 25 MByte free, the kernel
considers the machine overloaded and swaps out the few processes that just
got some pages paged in!
I've watched this going on for more than ten minutes without being able to
stop it. The only solution is to not allow any user action, to make sure all
processes are in I/O wait and not being paged in. Then I try to kill the
biggest background process (with my shell being paged in and swapped out,
it takes up to half a minute to enter a command!). Once there is no process
remaining who needs a lot of paging in, the situation returns to normal.
Than the user can continue to work and everything is okay, 'til the next
compiler run with optimization enabled ...:-(.
The problem results from a coincidence of facts.
1) HP's aim is not to deliver a reliable and user friendly system,
but to have their system being compatible to certain standards.
While standards conformance isn't a bad thing, there are lots of
things that aren't mentioned in any standard, but are important
to system management or ease of use. The main advantage in
standard conformance is portability of commercial software.
But then its simpler to port to a real BSD or AT&T unix instead of
HP-UX. (And I can tell you of problems in porting software to HP-UX
that runs without problems on DECstations or Suns... See below...)
2) HP tries to prevent you from buying third party peripherals.
We have 4 CS-80 drives with 300 MByte each. I had (naively)
expected the system throughput to improve, with more drives
connected. But then I realized the limit being the HP-IB !
While I'd consider the drives slow (~750KByte/sec), the bigger
problem is the maximum bus capacity. We urgently needed a
SCSI controller to connect faster drives. This controller
is available within few month, since the time we ordered the
machine. It was announced for the (hardware compatible) CIO 3000s
one year ago, so the hardware seems to exist, but we couldn't get one.
3) We urgently need the SCSI controller to connect an EXABYTE drive to
the system. We (and lots of other nuclear physics institutes) collect
our experimental data on EXABYTEs. Now I've got to know, that HP has
disabled EXABYTE support in the soon to be released HP-UX 8.05.
This means that our 9000/835 is finally 'dead', without even *once*
having been used to perform the task she was bought for!
I understand, that HP supports DAT and is not interested in the
spreading of EXABYTEs. We consider them superior to DAT (for what
we need them for), but HP *knows better than we* what our needs are.
4) We bought our 9000/835 under the precondition that a special VMEbus
interface be available. This was a top priority requirement, because
of our analyser system being changed from a PDP 11 to a VME based
real time system. After we got the system (without the VME interface)
we were informed, that the development work was canceled. We had already
paid for the interface (and we had to pretend it was already delivered),
so we couldn't do much about it. The problem was, that HP sales had
promised something absolutely unrealistic (the fast delivery of a
non existing product), and the HP technicians couldn't help there after.
(That happened to another physics institute in cologne university as well.
HP sales promised certain features that were technically impossible, but
you can't simply return the product if it doesn't work, because of the
way its financed. If we had returned our HP 9000/835 when we noticed it
to be unable to perform its task, there had been a big risk of the money
being returned to the state, without giving us the choice to buy from
another vendor. Maybe one or two years later ... But that is a problem
of the state bureaucracy (sp?).)
We finally got (more than one year delayed) a VMEbus interface, but its
of no use because its only 10% of the required speed ...
The problem in many cases was simply arrogance in the behaviour of HP.
They offer some very good products, but that's no reason to prevent us
from using anything HP doesn't offer (like EXABYTEs).
HP doesn't consider some OS features important, but I do, because I've
lots of trouble because of them missing.
2 weeks ago somebody from HP posted a reply to the request for variable
sized partitions. He said, that HP sure had evaluated the possibility to
offer var.sized partitions. But he didn't think people would pay for it,
so it shouldn't be included in the OS. That's a very annoying opinion.
I know of *no* other UNIX system that doesn't offer var.sized partitions.
And they *were* part of the BSD unix, that is the base of HP-UX !
There were many times I *really* had needed them. We have lots of trouble
with the HP-UX printer spool system (System V.2 compatible with extensions).
One problem is the fact, that I can't put the spool directory on a partition
of its own. That means, that it shares a common partition with user data!
And that means that users filling the partition prevent everybody from
printing because of lack of spool space. Originally the spool directory
is on the root partition. But there are the mail and tmp directories and
other growing directories as well and it wasn't big enough.
On the machine that finally functionally replaced our HP 9000/835 (can you
functionally *replace* something that was never operational ?), we have
4 1GByte drives, each of them partitioned in a non standard way.
That gives me 4 16MByte partitions (for root, 2*tmp, spool) 4 swap areas
and 4 900MByte partitions (for system + sources, user, 2*experimental data).
This wouldn't have been possible with HP-UX because of missing flexibity.
(Besides, we had got ONE 1GByte HP disc for the price of all FOUR we have...).
There are other reasons, eg. missing system calls that make some common tasks
hard. For example the renice sys.call misses (changing priority of running
batch job), althoug all data structures exist. Its simply 20 lines of kernel
source commented out. The same is true for adjtime(), which is required to
adjust the times of networked systems. Somebody wrote a daemon process that
patches the kernel variables (normally set by adjtime) to simulate the
standard behaviour. Again the data structures are available, just the system
call to access them is taken away. I was very supprised of the system time
spent in servicing NFS requests. Many operations that don't result in more
than 2-5% system time on other machines, need 20% and more in HP-UX.
This is true especially for network operations NFS and X)!
It takes our 9000/835 about 30 seconds to load a high res gif picture and
put it on the root of our tektronix X terminals. Its about 10 times faster
when I use a DECstation to load it onto the same display!
I've several times noticed a transfer via ethernet to slow down to 10KByte/sec
with the max being about 300K/sec. Between two DECstations I reliably get
values of more than 900KByte/sec.
Again: The problem is not the (very reliable) HP hardware. Its the habit of
HP as a company, that knows what their customers need. They speak about the
cost to implement features into their OS, which in fact already were there.
I think that Sun is not only interesting because of the large support by
3rd party hard- and software, but also because they actively work on SunOS.
(Sometimes the new release has nasty bugs, but you get patches via anon.ftp !).
I've seen 3.5 MByte/sec disc throughput on a Sun Sparc through the file system,
and while my DECstation can keep up with a 2.3MByte/sec SCSI disc when
directly reading through the device driver, I only get 1.2MByte/sec on the
same drive through the file system. This is mainly because of the work spent
by Sun in improving the I/O system. (I know, HP has announced very high disc
speeds for the new 9000/7xx, but I don't believe them 'til I've seen them.)
I know, there will be Suns at least as fast as the Snakes before end of the
year. When I had to choose a machine to be used instead of our HP, I decided
to buy a DECstation 5000/200. Today, maybe I'd take a Sparc 2.
The 350.000,-- DM (about $200,000.00) spent on the 9000/835 are wasted.
It doesn't even work well as a machine to hang X terminals on, i think its
because of the large overhead of TCP in HP-UX 7.0. We had really thought
about asking HP to take it back, but it was impossible, because of the
state funding and the conditions we got the money under.
Sorry about my problems expressing my thoughts in english and for the
explanation of facts that eventually are really of no importance (sp?)
to you. I know of several unlucky HP customers. Maybe HP really knows,
what *you* need. Then you might go and by their products.
Its very clear, that we aren't going to buy any computers from HP within
the next years.
Anyway, get one server machine with lots of memory, connect fast X terminals
to them and don't use the console as X terminal. (We don't use our DECstation
as X display. In fact, we choose the cheapest black&white display and spent
the difference in a further X terminal... If we use the DECstation console, the
X server can easily consume 100% cpu, making the other users quite unhappy.)
BTW: I didn't have a chance to see the HP RX/700 X terminals. But I
think they might have a fan like the previous generation (X/700).
Its often the case, that you get them shown in a noisy place (next to
other computers harddiscs and fans). I consider the fan very annoying
and choose X terminals without fan (after having used one with a
relatively quiet fan for some weeks, it made a lot of difference, though).
The tektronix X terminals we have, will become 25% faster with the next server
release (announced for end june). That will make them faster than the RX/700,
they will be fastest on the market again. If you want to have a look on them,
be sure to try the XP-29-CM (1280x1024,256 colors) with the 17" Sony Trinitron
(prices in germany, I'd expect it to be about $5,000 in the US). The cheapest
version (XP-21,1280x1024,black&white) is not only really cheap (~$2,000) but
also very fast, alot better than eg. a Sparc SLC.
Ok, now its 4:20 in the morning, really time to go home ...
Bye,
Stefan
--
Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany
se@IKP.Uni-Koeln.DE [134.95.192.50]
From kd4nc!km4ba!alan@gatech.edu Fri Jun 7 00:46:42 1991
From: Alan Barrow <km4ba!alan@gatech.edu>
Just a quick explanation:
DIO is the "old" 16 bit I/O channel for 9000/S300's.
OK for it's day, but pretty slow for disk I/O.
(Works fine for printers, tapes, etc.) Much of the
"HP=slow I/O" myth is from systems using this type of card.
DIO-II is the 32 bit I/O channel used on 9000/300's & 400's
in the last few years. It is a wider bus, and is much faster.
In addition, many of the newer scsi & hpib cards are integral
to the CPU, and do not use a "bus slot". These daughtercards
are faster yet.
The filesystems has been tweaked along the 6.5/7.0 timeframe
for improved scsi I/O as well. (8.0 is shipping now)
Note some low end config's intended for use as diskless
workstations did not include high speed disk I/O on the base
unit. This was sometimes exploited by competitors to show
how "slow" HP disk I/O was.
Current HP-IB is really not that bad with decent disks
and a high perf card. SCSI is much more flexible, however
and is really where HP (and others) are headed.
So.. don't let file I/O scare you off on snakes & other
current generation HP systems.
Try it yourself! I think you will be pleased.
Hope this helps you understand the DIO nonsense! :-)
Good Luck!
Alan Barrow
From pjr@ariel.ucs.unimelb.EDU.AU Fri Jun 7 01:07:05 1991
From: Peter Rayner <pjr@ariel.ucs.unimelb.EDU.AU>
Um, you have a problem here, you don't know how to compare the performances
of the two machines because you don't know what you want to run on them. I
don't know if it helps but there are lots of questions you haven't included
like
1) multi-user performance (maybe not a problem)
2) quality of system software
3) future growth paths
4) hardware reliability
If speed is your question then my guess would be there's not much in
itsince most of the comments I've seen show a HP-700 as about 2xSS2 and the
IPC about 0.5xSS2. The old result says it's always better to have one big
machine for solving a problem instead of 3 smaller ones, after all that
means you can dedicate all the resource to one problem if you want to at
some time. Also think about how much time you want to spend administering
and learning about your new machine, this will presumably be much lessened
with a Sun since there is expertise on the ground. Overall I really
couldn't offer advice, we bought Sun last time for our basic user needs and
will probably buy HP next time (headless if we can) as a compute server.
Neither choice will be disastrous I'm sure.
From bt@irfu.se Fri Jun 7 04:33:21 1991
From: Bo Thide' <bt@irfu.se>
You (Kevin Nechodom) write:
>
> My data is strictly anecdotal, both from Sun and independent people on campus.
> My suspicion is that they are comparing against the old HPIB.
The 700 series workstations don't come with HPIB.
Below you find some I/O benchmarks on the slowest HP700 (the 720) with
the pre-release OS HP-UX 8.01 (untuned compilers) and the fastest Sun
(SparcStation 2) I got from the independent French Unix Users Group. I
think you have to agree that they show that HP is a much better I/O
performer than the SS2. Show this to your friends and ask for comments.
I am interested to hear what they have to say since we are looking at
the 700's very seriously.
Bo
--
^ Bo Thide'--------------------------------------------------------------
|I| Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
|R| Phone: (+46) 18-303671. Telex: 76036 (IRFUPP S). Fax: (+46) 18-403100
/|F|\ INTERNET: bt@irfu.se UUCP: ...!mcvax!sunic!irfu!bt
~~U~~ -----------------------------------------------------------------sm5dfw
-------------------
HP9000/720 (Cobra):
-------------------
Identification : HP9000/720 HP-PA 89 HP-UX 8.01 50 MHz 64 MB 2*200 MB
SSBA 1.21F (27/02/89) run No. 4 : BEGIN at Fri Feb 22 14:44:45 WET 1991
Command C : cc -D_XPG2 -Wl,-a,archive +O3 I Command Fortran : f77 -Wl,-a,archive -O
unix=hp-ux SVR3
define=-DTERMIO -DSysV
Number of Processes running on the system when the SSBA starts = 22
machine = HP-UX cobra1 A.08.01J A 9000/720 15904141 (uname)
whoami = root pty/ttyp2 Feb 22 14:36
value of HZ = 100 /* ticks = 100 (times method) */ (calculation)
Number of processes available for the user= 254
disk: 10.000 Mb (512 bytes io) throughput 1492.37 Kbytes/sec 6.7 seconds
Filesystem Throughput Test :
File Size: 125 blocks
Write: 835.8 Kbytes per second (standard deviation 55.8 Kb)
Read: 12500.0 Kbytes per second (standard deviation 0.0 Kb)
Copy: 835.8 Kbytes per second (standard deviation 55.8 Kb)
File Size: 250 blocks
Write: 1706.4 Kbytes per second (standard deviation 68.7 Kb)
Read: 12500.0 Kbytes per second (standard deviation 0.0 Kb)
Copy: 1219.4 Kbytes per second (standard deviation 612.8 Kb)
File Size: 500 blocks
Write: 2464.5 Kbytes per second (standard deviation 144.7 Kb)
Read: 10000.0 Kbytes per second (standard deviation 0.0 Kb)
Copy: 2083.3 Kbytes per second (standard deviation 0.0 Kb)
File Size: 1000 blocks
Write: 2969.8 Kbytes per second (standard deviation 731.5 Kb)
Read: 9090.9 Kbytes per second (standard deviation 0.0 Kb)
Copy: 2075.6 Kbytes per second (standard deviation 791.2 Kb)
---------------------------
Sun SparcStation2 (Calvin):
---------------------------
Identification : SPARCstation 2 (4/75) SPARC Cypress SunOS 4.1.1, Fortran 1.4, C 1.1 40 Mhz 16 Mo 669 Mo SCSI
SSBA 1.21F (27/02/89) run No. 1 : BEGIN at Thu Nov 29 10:14:26 WET 1990
Command C : cc -O4 I Command Fortran : f77 -fast -O4
unix=BSD4.2 SVR3
define=-DVMUNIX -DBSD4v2
Number of Processes running on the system when the SSBA starts = 12
machine = SunOS taurus 4.1.1 1 sun4c (uname)
whoami = root tty?? Nov 29 10:14
value of HZ = 60 /* ticks = 18000 (methode setrlimit) */ (calculation)
Number of processes available for the user= 127
disk: 10.000 Mb (512 bytes io) throughput 714.26 Kbytes/sec 14.0 seconds
Filesystem Throughput Test :
File Size: 125 blocks
Write: 407.0 Kbytes per second (standard deviation 13.1 Kb)
Read: 6469.3 Kbytes per second (standard deviation 189.9 Kb)
Copy: 442.9 Kbytes per second (standard deviation 21.7 Kb)
File Size: 250 blocks
Write: 310.9 Kbytes per second (standard deviation 0.0 Kb)
Read: 6466.5 Kbytes per second (standard deviation 97.4 Kb)
Copy: 332.7 Kbytes per second (standard deviation 2.1 Kb)
File Size: 500 blocks
Write: 294.6 Kbytes per second (standard deviation 0.0 Kb)
Read: 6383.9 Kbytes per second (standard deviation 94.9 Kb)
Copy: 303.3 Kbytes per second (standard deviation 11.0 Kb)
File Size: 1000 blocks
Write: 284.9 Kbytes per second (standard deviation 0.0 Kb)
Read: 6369.9 Kbytes per second (standard deviation 70.7 Kb)
Copy: 289.4 Kbytes per second (standard deviation 0.5 Kb)
From johnny5!garvey@quick.com Fri Jun 7 09:03:02 1991
From: Joe Garvey <johnny5!garvey@quick.com>
|
| My department has at least 3 independent systems on Sun, and I am wanting an
| HP 730. I have put together a system of one 730 server and two of the new
| 700/RX monochrome X-terminals for about the same cost as 1 Sun SparcStation 2
| and 2 IPC's. The HP system would have about 1G on two disks (1 controller),
| while the Sun system would have about 1.3G on two disks and 200Mb locally on
| each workstation.
Nice configuration.
Sun is trying to confuse the issue (a tactic when they feel they've lost,
and right now they are behind technically). The new HP machines are screamers.
They have way more performance than Suns. I'm *VERY* familiar with HP's CISC
workstations, and I know that HP specs conservatively, while Sun specs
agressively. You're one the right track. You'll find that the easy of updating,
the better perforance and reliablity, make the HP worth it. You'll also find
that their software is very free of bugs compared to Sun. They're support
is also better.
The only down side, is software availablity. I have the extra time to spend on
a Sun, and the availablity of software is an overriding issue. It sounds like
you have fixed plans. If you can get the software, then you're proposed
purchase only has one problem. They guys with Suns will want to use your
machine. Hp's software availability will get dramatically better over the
next 24 months too. A couple of years from now, I expect there will be no
difference.
Also, the HP is the next in the series of evolving workstations. It will
be a viable architecture for years. Sun 2, (and my SS1+) are dead dodos.
Sun will come out with an entirely new box for the next rev. Bying an
SS2 now means near term obselence (sp?).
Ask your boss how he's going to feel when everyone says scrap the SS2 in
12 months, and he's asked to pay for a new "better" one. Or if you have bean
counters, ask what the effect is of a 24 month depreciation vs a 60 month
depreciation will have on the dept's budget? These are probably realistic
schedules.
I had a group of HP cisc machines, *MUCH* less performance than your machine.
My net also had X-terminals. You'll never notice the X-terminals. The actual
issue is what is the performance in the terminal itself for running X. Ignore
the machine issues.
Putting 425s in will be much easier than than adding a Sun workstation. HP's
dataless architecture is vastly superior to Suns.
If you add more HP compute nodes, put local swap disks on. This is the one
thing that can hurt you. It sucks up network bandwidth, and CPU server cycles,
but this is independent of Sun/HP. Never have a diskless node, just a dataless
node. The issue here is not file access, but swapping over the lan. It gives
your system the "jerks". Everything stops to swap, then jerks forward.
| I anticipate mostly database (don't know what yet) and stats (probably SAS)
| applications. I have been told that Sparc floating point is abysmal, but that
| DB and stats are mostly I/O intensive, and Sun is better than HP for I/O.
I wouldn't bet on that for the new machines. The issue is the disks, not the
machine. SAS will be floating point intensive. The HP is a clear winner here.
The sparcs are closer to CISC in this area.
| My boss would like a good level of cooperation within the department, and it
| seems that buying Sun would do that.
Nah. Six of one, half dozen of the other. They both run unix, tcp/ip, x11.
| My own biases are towards HP. We have been an HP3000 customer for over 11
| years, and I have been very happy with their machinery and support. I chuckled
That's probably why your boss is on your case. You've made the right call.
Possibly for the wrong reasons. I've been involved with Sun and HP, with
a configuration much like you describe. Like I said above, after a little
while you'll find the Sun guys wanting access to the HP.
PS. HP has ksh standard. :-) That's enough to give it my vote.
PPS. Bash is a good imitation of ksh, if you run a Sun.
Hope that helps.
--
Joe Garvey uucp: sumax!quick!johnny5!garvey
J5 Research internet: quick!johnny5!garvey@sumax.seattleu.edu
Bothell, Wa., 98021 AT&T: 206-481-8023
If you got this far, you definitely to be congratulated! So, what did I do?
I just put an HP 730 and 2 700/RX X-terminals on order. One of the clinchers,
but by no means the only one, was the fact that SAS ordered hundreds of these
stations for their own development. I figured that they have put their own
corporate name on the line, and I could sure benefit from using the same
platform, virtually guaranteeing that I will get the most up-to-date version
available from them.
Once again, I would like to thank all these respondents. You were all a
tremendous help!
Kevin Nechodom
University of Utah CSSRD/STACC
420 Chipeta, Suite 220
Salt Lake City, UT 84108
nechodom@cc.utah.edu
"Ok, I'm opinionated! So what!"