hvt@tnocsda.UUCP (henq) (05/06/86)
Follows a compilation of the reply I got from my Apollo or Sun question.
Thanks to all the guys who took the time to type in their experiences.
Apperently no 'consumer test' in a officialy published magazine exists.
If you wants to discuss the things that follow, you can e-mail
your comments to me, I will compile them into a newer version of this document
and repost it.
-henk
...mcvax!tnoscda!hvt
Thu, 17 Apr 86 18:32:51 +0200 (MET)
CIAO
I am very interested in the results of your comparison
between Sun and Apollo. I have done some work on each
of them but have not compared them. If you find any benchmarking I would
appreciate you sending it to me. I am not versed in the architectureal
diferences of the machines, but I do have a knowledge of the CAD market.
I think it would be great if someone posted some reviews to the net.
Other tidbits... (No claim as to accuracy)
1) Sun will come out with a low end color system soon
2) Apollo's new DN3000 uses 12 MHz 68020's because of
sync problems with the 6 MHz PC bus. This may indicate
future problems as the 020's go to higher clock rates--ie Sun
will be able to speed up their systems and apollo won't
3) The Sun 3's get really expensive if you add the GP and
GB to the model 160's. It seems that they are a requirement
for reasonable graphics. (The DN570 and 580 are mega bucks too)
4) Apollo claims their new DN580 with graphics accellerator
is the fastest 3D machine on the market (although I think
it is compareable to the SGI IRIS machines if you add shading
and shadows...) for 3D transformations and clipping.
5) Both Apollo and Sun have a big lead over DEC and IBM simply
due to the volume of applications software available. DEC
will be able to use its VMS and ULTRIX base, but those are
not really geared to CAD applications.
6) Dec will probably soon announce a 3D version of their VAXstation
GPX, although given DEC's current pricing strategy I do not think
that they should be seriously considered unless you have a VMS base.
7) IBM is beta testing (i read it somewhere) faster (4 MIPS?) versions of the
PC RT. Currently the machine is a dog, but if IBM puts better
graphics on it and lowers the price it might become a real machine.
The RT uses 2 micron CMOS and thus should be easy to speed up via
diferent semiconductor processing techniques.
8) I am not quite sure of the diference between the raster based
Sun systems and the display list based Apollo's, but I would bet
that in applications that require a lot of transformations on symetric
objects (things that can be represented by boxes, circles...) the
Apollo will blow the sun away (especially at the high end). On uneven
surfaces (imaging...) the Sun will be superior. Sun probably
is superior for
low performance applications too, as I would guess that raster based
technology requires fewer chips and is thus cheaper!!! (but don't
believe that I know anything about design/cost considerations)
9) The Apollo 5XX systems use an internal NONSTANDARD vmebus and hooks
up to peripherals through an optional multibus module. This is the
most bizare bus architecture I have ever heard of --> I have no clues why.
Anyway --> this is some stuff that I have figured out.
It is certainly not to be taken as the opinion of AT&T, but I hope it helps.
ED BARLOW
MTS, AT&T Information Systems Labs
ihnp4!mtuxn!smile
From: Peter Lamb <mcvax!ethz!prl>
Date: Wed, 16 Apr 86 22:56:07 -0200
Organization: ETH Zuerich, Switzerland
I am managing the systems on a bunch of VAXes,
3 Suns+file server, and 3 Apollos+file server.
The views here are based on Sun Unix 4.2 Release 2.0, and
Apollo SR9.0
The short summary of my opinion is that Apollos
stink if you want a Unix system. If you want to use
their native OS (AEGIS), perhaps it's a different
matter.
We will continue to use them because we have some
binary-only software which runs on Apollo and not
Sun.
In article <138@tnocsda.UUCP> you write:
>
>
> SUN or APOLLO ?
> APOLLO or SUN ?
>
>
SUN any time, thanks.
>Which one is the safest bet for the future ?
NO IDEA!! I have heard a rumor that UCB have an order
for 1000 (!!) Sun workstations. If that is true, it
explains why the delivery time on them is so long.
....
The sun interface to its screen windows seems to
me to be better than the Apollo one: much more use is
made of the mouse, and it has popup menus for window
control.
>Is the IBM PC RT (if that's it's name) a alternative ?
The PC RT seems quite nice: it does about 80% VAX785
on a primes seive benchmark. But a SunIII goes about 50%
FASTER than the 785 on the dhrystone benchmark (integer arith
only). The C optimiser on the RT does virtually nothing,
if it were fixed, then the RT, I would guess would come
quite close to the 785.
>
>PS to start a few rumors:
>
>- unix on APOLLO is kind of emulated and performs
> not so good (I heard)...
Completely, utterly totally and gruesomely true!!!
Some examples:
1) Run pst (process status table - AEGIS command)
and then Unix ps (and wait, and wait, and wait)
2) It is not possible to make a device inode
(mknod) from in unix.
3) It is not possible to make an ACCOUNT from unix.
4) The permissions system underlying AEGIS is much
more complicated than the unix one (argueably better,
even), and some of the differences show up inside UNIX.
>
>- why did Apollo turn to the 680X0... ?
>
Did they ever use anything else? The Apollos we have
(DN300, DN320, DN660) are all 680X0's except the DN660,
which is a tty bitslice machine which emulates a 68010.
As far as I know, the new Apollos are 68020's. Perhaps there
were earlier Apollos which didn't use the 680X0
>- The Apollo Domain network is so much nicer integrated
> in the whole system...
I disagree. The Apollo Domain is better than the old
Sun NDS (network disk system), but the Sun NFS (net file
system) is VERY nice.
The domain system has an 'over-root' called // after which
comes the name of the machine, then the path name: eg.
//my_machine/usr/bin
Symbolic links can then be used to make remote file
systems appear in sensible places in the local file system.
However, I was reading an installation guide the other day,
which said that in order to do the installation, you had
to remove all these links.......
another problem is one associated with symbolic links being
one-way: for example if
/usr/users/me (on my local machine) is symbolically
linked to //elsewhere/usr/users/me, and I go
cd /usr/users/me; cd ..
then I am in //elsewhere/usr/users, not /usr/users.
On Sun NFS, the mount command has been extended to
allow
mount machine:/path/name /local/path/name
The semantics of this is that the remote subtree is mounted
on the local file system. All machines must have their own disk
partition somewhere for their local root. This can be either
on a local disk or on a complete (sub-)partition of a remote
disk. The remote machine has a list of exported mount points,
and only the subtrees below these mount points can be mounted
by a remote system.
One thing much better handled by Apollo are permissions
and privileges. The problem with Unix on the Suns in this
respect is that on a remote machine, it may be sensible
for some person to be root who would not be allowed to
be root on (say) the file server. The control on this
is by a list of trusted machines for the TCP/IP commands
(rlogin, rcp, etc), however all that has been provided
for the NFS is a single kernel flag to say if the server
trusts all or none of the roots on remote machines.
The Apollo security system is much better, but incompatible
with Unix to the extent that there is no /etc/passwd file,
and all account administration must be done with AEGIS commands.
--
Peter Lamb uucp: seismo!mcvax!ethz!prl
earn: PRL@CZHETH5A
Institut fuer Integrierte Systeme Institute for Integrated Systems
ETH-Zentrum ETH-Zentrum
8092 Zuerich 8092 Zurich
----------------------------------------------------------------------
Please post your findings in regards to the comparison between Sun
and Apollo. In regards to the PC RT, Sun and Apollo don't think much
of it (according to a Computerworld article), and neither do I, after
reading a writeup of it.
Thanks,
Terry Poot
Nathan D. Maier Consulting Engineers
(214)739-4741
Usenet: {seismo!c1east | cbosgd!sun | ihnp4}!convex!infoswx!ndm20!tp
CSNET: ndm20!tp@smu
ARPA: ndm20!tp%smu@csnet-relay.ARPA
----------------------------------------------------------------------------
Maybe this will be useful -- I posted it to sun-spots@rice.arpa and
apollo@yale.arpa a few months ago.
I used Suns at Rice for several years, since the original Sun-1 and Unisoft
V7 Unix. (In fact, I used to moderate this list.) I've been using Apollos
for about 6 months here at Bellcore. These are a few comments about the
merits and problems of the Apollo relative to the Sun. (Note that my Sun
experience goes up to Sun 1.3, not 2.0, and my Apollo experience goes to
SR9.)
First, I have to confess that even on the Apollos, we use Unix exclusively.
(For those who don't know, the Apollo runs a kernel operating system called
Aegis. Libraries and server processes sit on top of that kernel. The
"Domain/IX" product is a Unix emulator for both 4.2 and System V,
simultaneously if you like, and provides most of the Unix system utilities,
libraries, and system calls.)
We use Unix mostly for reasons of portability and familiarity. Regardless
of the merits of the native Apollo operating system, there's no way a
program written with it will run on another machine, while with Unix,
there's at least a fighting chance of writing portable code.
APOLLO MINUSES:
Because the native operating system is not Unix, there are an entirely new
set of system management problems. You have to learn a whole new set of
commands, remember where different configuration files are, and so forth, to
be an effective system manager. This took me about a month or so. The
problem was greatly complicated because most of the Aegis commands have
almost exact Unix equivalents, but the names have been changed. For
example, "list directory" is "ld", not "ls". "Move file" is "mvf", not
"mv". It's an annoyance. Once Domain/IX is in place, these problems
almost, but not quite, go away.
All of 4.2 BSD is not supported. For example, the syscall interface to the
kernel is missing, as is the SIGIO signal. The 4.2 print spooler (lpr, lpd)
and the Unix graph(1) command are not present. I'm sure there are other
things that I haven't missed yet. I am not too familiar with System V and
we aren't using it, so I don't know what's missing there.
Because the C compiler is a native Apollo compiler and not the Portable C
compiler, there are subtle C language incompatibilities. Also, there is no
assembler in the standard distribution, the compiler produces error messages
in a different format, and the code quality is different between Apollo C
and PCC. (It's not clear which is better. Under SR8, Apollo C was clearly
inferior to PCC, but the situation has improved under SR9.)
Apollo uses a TCP/IP derived from the old BBN sys.10 process-based TCP,
which means there are a different set of management commands from the ones a
4.2 user would be used to (ie, different host tables, no netstat, route,
arp). Most of the same functionality is present, it's just different. (The
network libraries, sockets and so forth, are identical to 4.2 BSD's.)
The object and executable formats are unlike Unix's, so programs that dump
memory state don't work. In addition, the symbols etext, edata, and end are
not provided.
To make a sweeping comparison, the Apollo (with a 68010) is slower than the
equivalent Sun. Using the Dhrystone benchmark, an Apollo DN320 with an FPA
comes in at 793, while a Sun 2/120 without FPA runs at between 1100 and
1200. I don't know the relative clock speeds of the two machines, or the
memory wait-state situation on the Apollo, or whether the 68020 versions
will be different.
In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless
Sun (running ND, not NFS) with 2 meg. One should take into account that
this includes the (presumably) extra overhead of running Domain/IX programs
as opposed to native Aegis commands, which we don't use much. Some
commands, particularly those that deal with directory reading or writing
(like "find") are painfully slow.
The standard Unix debuggers (adb, dbx) are not supported on the Apollo. The
standard editor is nicer in some ways, worse in most, to the Sun dbxtool.
It's certainly different - another training problem.
The Apollo's performance is not "predictable" to me. There are sometimes
long pauses for no good reason. This may well be an artifact of my
unfamiliarity with the internals of Aegis, and strange interactions with the
Apollo virtual memory and single level store.
The Apollo documentation for Domain/IX is almost a straight printout of the
Berkeley VAX documentation. Usually the differences and limitations of
Domain/IX are not mentioned. As documentation for someone unfamiliar with
Unix, it suffers from the typical Unix problem - you have to know a lot
about Unix already before the documentation makes sense. Apollo should make
an effort to try to expand on the conventional documentation. They have a
short guide for new users, but nothing really for systems programming. (Sun
has more or less the same problem, but since they've had Unix longer, their
documentation is somewhat further along. It still suffers from emphasis on
novice users, though. I don't know if the 2.0 documentation is better.)
I like the Sun keyboard and optical mouse much better than the Apollo
keyboard and mechanical ball mouse. The Sun window interface has somewhat
better mechanics; Apollo window placement, cursor treatment, and general
user interface have some problems.
APOLLO PLUSES:
Aegis is a much "cleaner" operating system than Unix in a number of ways.
For example, the single level store allows very nice shared libraries to be
implemented. Rather than including the object code for all of the C library
with every program, as Unix does, Aegis does dynamic binding at run time.
The executables are much smaller, and the system can be changed without
rebinding anything. I have executables from 4 major releases of Aegis ago
that still run with no changes. One could claim that from a design
standpoint, Aegis is more consistent than Unix. It has more support for
record-oriented files, which might be important for some applications, like
databases. (You can't use this and remain Unix-compatible).
Apollo has had transparent access to files for much longer than Sun has.
Therefore, the performance seems to be much better (I have only limited
experience with NFS, but long waits for file opens don't occur on the
Apollo.) The performance of Sun ND seems superior to Apollo's distributed
access, but remember that ND didn't allow read/write file sharing among
machines.
In order to run a single ring of machines, much less system administration
per processor is needed on the Apollos. It is almost as simple as plugging
a new machine into the ring, turning it on, and using it. The Sun requires
a much more complicated procedure to configure a new machine. A diskless
Sun has to be administered like a separate machine, while a diskless Apollo
doesn't have any separate administration problems.
The Apollo user interface has some nice features that the Sun lacks, like
scrollable back histories, and command resubmission and editing. There is a
simple (almost too simple) pervasive editor that is always available on the
Apollo to do input editing. The Sun is much more oriented towards multiple
ASCII terminal windows.
The Apollo graphics package is considerably easier to use than the Sun
package, although of course neither is the least bit portable to other kinds
of machines or each other.
The Apollo error messages, both from system routines and the compilers, are
much better than the standard Unix messages found on the Sun.
We experienced a large number of CRT failures at Rice, and other groups at
Bellcore continue to lose Sun CRTs commonly. We have never had an Apollo
CRT go out on us (in two years with four to seven nodes). In general
hardware reliability seems higher on the Apollo.
Apollo seems to have a much higher commitment to software compatibility and
support across releases and different Apollo hardware than Sun does. With
Sun, we went through a large number of completely incompatible software
upgrades (Unisoft to Sun 0.1 to 0.3 to 1.0 to 2.0) across which most
graphics software broke completely. Apollo guarantees compatibility from
release N to release N+1, and in practice, across many more release levels.
The documentation for Aegis has a rich set of examples in several languages
for how to use most of the system interface.
As a company, Apollo has exhibited somewhat different tactics than Sun. In
the early days, Sun made a lot of promises and then failed to deliver.
Apollo delivered a product with full function but bad performance, then
concentrated on making it fast. Now that Sun can deliver, the difference is
less pronounced - but I still remember a year of not being able to do much
with Suns because the graphics and network software wasn't there yet.
THE BOTTOM LINE
We are getting our work done with the Apollo, working around the problems
caused by lack of full Unix support. In general we're happy, but we're also
scared that the CS research community is moving to Suns exclusively. It
seems clear that Sun's commitment to full native Unix is stronger than
Apollo's. We have already had some problems porting programs from Sun or
VAX to Apollo. While this can be chalked up in large part to sleazy
programming practices, that doesn't make the problem any more manageable.
In brief: For applications involving exclusive use of Unix, and contact
with the general research community, the clear choice for now seems to be
Sun. If you don't have the constraints of Unix and Unix portability, you
should give Apollo a look.
Mike Caplinger
mike@bellcore.arpa
ihnp4!bambi!mike
ps. I'm still looking for the perfect workstation. It's beginning to look
as though I'll have to build it. :-)
From: Arthur Wouk <mcvax!duke!wouk>
Organization: Duke University, Durham NC
The Sun people have acquired the best software people in the business,
including Bill Joy, but not restricted to UNIX types. This alone
indicates which way to go.
From: mcvax!motbos!cdx39!jc
To: tnocsda!hvt
> unix on APOLLO is kind of emulated and performs
> not so good (I heard)...
Not having more than a passing acquantance with Apollo, I can't
give any details, but there is at least one important consideration.
It is true that any sytem emulating another has an inherent cost,
there is often a benefit that makes it worthwhile. Thus, IBM's
VM system costs about 30% of the cpu cycles on a machine. But
lots of people are willing to pay this price for what it buys:
the freedom to run multiple operating systems simultaneously on
a single machine. Thus VM users can pick and choose between
software designed to run on DOS, CMS, OS/VMS, and so on. They
can even get a good version of Unix from Amdahl, and effectively
get a 60-user PDP-11. A 30% slowdown is a reasonable price for
all this. Similarly, people with VAXes often run VMS for its
realtime capabilities, with a Unix emulator, rather than just
Unix alone. As for Apollo, their Unix may not be super-fast,
but it isn't extraordinarily slow, either. If the benefits of
the underlying Apollo system are of value to you, a somewhat
sluggish Unix layer may be an acceptable price to pay.
> why did Apollo turn to the 680X0... ?
It's a good little cpu.
> The Apollo Domain network is so much nicer integrated
> in the whole system...
On the other hand, one of the dreams of the Networking folks
is to somehow integrate all the disparate hardware and software
into one humongous, user-friendly, world-wide computer system.
Several companies make their own proprietary distributed file
system, and give you great access as long as you buy one of
their systems, but don't do much for you if you need to exchange
data with another kind of machine. If you wish to deal with
computers from different sources, you might not want a single
well-integrated system. You might prefer a well-modularized
one, instead. Then you can add a completely new layer that
ties the modules together into a package that looks unified
to people (and programs) that call on it.
We're looking into similar questions around here (Codex Corp,
a division of Motorola); at the same time people in various
departments are going ahead and buying whatever computers
seem to meet their needs of the moment. Fun...