[comp.sys.hp] Response to Comparison between HP and Sun

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!"