[comp.sys.apollo] Essay on DN10K

scheinin@mrlaxb.mrl.uiuc.edu (Alan L. Scheinine) (05/01/91)

   I sent a letter -- which in part is similar to the following text --
to Apollo about seven weeks ago.  I sent it to two people who knew me from
my beta-testing work, and to someone else who had replied to me previously.
I kept asking for a reply but got just two things: one insult; and from
another person (about a week and a half ago) a recipient who is very much
on the technical side rather than marketing, said that while he has no
control over policy, he would forward the letter to someone in marketing
who could answer it.  I've not heard anything more.

   When I studied the mini-supercomputer and superworkstation market two
and a half years ago, my decision to recommend the purchase of a DSP10040
was due to the clear-cut performance advantage.  The purchase decision
was not based on customer loyalty: neither we nor the computer centers
that we used had Apollo workstations.  Nor was it based on Apollo
marketing: the Chicago office of Apollo was spread so thin as to be
nearly invisible.  The decision was based on price and number crunching
speed.  Let me give an example of the thoroughness of the research done
by this group.
   Benchmark programs run on an Alliant did poorly for some routines
involving sines and cosines.  The local supercomputer center, NCSA, had an
Alliant and we discussed performance comparisons with people there.  We
discovered that Alliant had an employee with an office at NCSA and he agreed
to have experts at Alliant look at the particular benchmark programs that
did not do well on their machines.  It took about two more months and many
phone calls to reach the point that we felt we had been completely fair in
our benchmarking of the FX/8 and FX/80.  That is but one example of how,
for every machine that was possibly within the budget, we made sure it
was not dismissed prematurely.  Only after about eight months of research
was the Apollo Series 10000 chosen.
   In the past two years I have spoken with many people about the Apollo
Series 10000.  Nearly everyone agrees that when it was introduced, it
was the best number cruncher, aside from supercomputers.  The Apollo
staff deserves a great deal of praise for creating the first workstation
to truly deserve the description: superworkstation.
   The upgrades to the Series 10000 scheduled for this year, e.g. the
PRISM II CPU boards, are too little and too late.  What I find perplexing
is that everyone knows this, but Apollo does not accept the fact.  I first
expressed concern to my local sales representative and to some field
engineers, after it was announced that PRISM II would only be twice as
fast and that the bus speed would not be increased.  Please note that
PRISM II was announced on October 25, 1989, but will not be available until
the middle of 1991.  I later expressed my concerns to a workstation manager
at Apollo, Chelmsford; in particular, pointing-out the closeness of the
competition.  He said that Apollo/HP would continue to support the Series
10000.  Continued support is appreciated, but one can doubt such a
statement because it is not realistic.  For example, the Series 10000 was
intended to be a super-visualization platform as well as a number cruncher.
But now, X windows for the 40-plane graphics board will not be supported.
   At this time, the closeness of the competition is even more clear.  The
IBM RISC System 6000 is comparable to PRISM II.  Moreover, it is likely that
by the end of this year IBM will announce some faster machines.  Also, the
MIPS R4000 chip will soon be available.  A key factor in the MIPS chip
competition is the number of players.  Many companies already have experience
with the R3000, so it will not take long to put into production a R4000-based
machine.  Moreover, Stardent, DEC and Silicon Graphics have multiple CPU
machines.  The MIPS R4000 is not comparable to the PRISM II CPU.  However,
the closeness of the MIPS-based competition will make it difficult for the
Apollo Series 10000 to standout as having a clear-cut performance advantage.
If the market share is too small, Apollo/HP will not be able to justify
software improvements.  Moreover, vendors will have no interest in porting
their products.  One could argue that PRISM II is better than the compe-
tition, when one looks at the competition during 1991.  But PRISM II will
not remain in that position during a reasonable pay-back time.  Users and
third party software vendors can see that clearly.  I've saved the worst
for last.  A diskless PA-RISC model HP 9000/720 will be about 40% less
expensive and about 20% faster than PRISM II.  (I was told that the list
price of the PRISM II CPU is $21,000.)  The lack of a future for the Series
10000 will mean a tiny market share.
   Apollo found a particular type of person (or research group) when they
offered the Series 10000.  The buyers were people who wanted great number
crunching performance in a workstation package.  These are the type of
people who can be expected to buy the newest PA-RISC machines.  Notice I
wrote "type of people" rather than "same people."  The people who actually
did buy the Apollo Series 10000, probably all feel that the ground has
slipped out from under them.  The Hewlett Packard marketing staff are in a
much better position to judge the situation, but permit me to speculate.
By giving the owners of DN10K's much less than they had hoped for, as far as
upgrades, HP has antagonized the market segment that they need for PA-RISC.
   When the PRISM I products were first being sold, Apollo announced that
they planned on improving the speed by a factor of three in two years.  It
was a disappointment to learn that the CPU speed would increase by only a
factor of two and that the rest would come from software improvements.  In
fact, even with software improvements, the double precision Linpack speed
will increase by less than a factor of two.  Apollo has not lived-up to its
commitment.
   The purchase of a DSP10040 was a major investment, a once-in-a-decade --
or even a once-in-a-career -- purchase.  We expected to be able to make
incremental upgrades that would retain the machine's status as a leading-edge
product.  Because that is not the case, Apollo/HP should now announce the
value of the machine in regard to a trade-in for PA-RISC.
   Though not officially announced, there was widespread talk by Apollo
staff that about one year after the initial Series 10000 product offering, a
single-CPU PRISM workstation would be released.  If that had occured, Apollo
would have had the product out before IBM's RISC System 6000.  The Series
10000 could have had a larger market.  Moreover, if HP had intended to
keep the Series 10000 as a leading edge product, they should have extended
the instruction set.
   The PRISM architecture could have been improved in many ways.  The
cache could have been made four-way set associative rather than direct-
mapped.  Also, the latest generation of floating point chips from
Bipolar Integrated Technology have a pipeline stage in the middle of
each operation, which as far as I know is not being used by Apollo.
If Apollo had extended the instruction set, the latest generation of
floating point chips could have made PRISM II three (or nearly four)
times faster than PRISM I.
   There are other, bolder, changes that could have been made.  As far as
I know, it is not possible to pre-fetch data into cache with PRISM II.
There should have been added a separate, independent but tightly coupled
processor for generating addresses.  Since the Intel i860 has three
separate instruction streams, each of which can use any chip resource; it
is not fantasy to advocate that PRISM II have two instruction streams, the
second of which just have access to integer arithmetic and memory resources.
It is my impression that generating addresses for fetching data can be a
significant bottleneck.  A related improvement would have been cache for
local data.  With the current PRISM design, if data is fetched and stored
in a different order (e.g. indirect addressing), then the data must be
written-back to reflect that reordering.  A cache for purely local data
would avoid the extra bus traffic of writing-back.  The registers serve the
same purpose, but the number of registers in PRISM II will be the same as
PRISM I -- as far as I know.  The concept of a cache for local data is
simply the idea of having enough local space to make pre-fetching useful
and being able to specify locations in that local space with address
offsets as well as directly.
   At the time PRISM I was introduced, it was a clear front-runner.  I
expected that the company that developed PRISM I would want to remain a
front-runner when it released PRISM II.  Instead, the Apollo division has
taken a back seat in HP's product development plans.
   I am a graduate student in physics with some background in computer
architecture.  I am not writing on behalf of my thesis advisor.  His views
on the subject may be different.  My remarks on the financial situation of
this research group are intended to be generic.  It seems to me that
obtaining funds for upgrading equipment will occur no more often than every
three years.  It is too early to say anything conclusively, but it seems
prudent to not purchase PRISM II.  Rather, one should wait for better CPUs.
Since PA-RISC will not have the Apollo SR11 operating system, an Apollo site
ought to consider the full range of available products, including IBM RISC,
when considering what to purchase during the next twelve months.
   Because the change of plans at HP will make the Series 10000 an antique
during this year, HP should provide a very generous trade-in value.  My
original purchase recommendation was based on having a product with a much
better future.  It is my understanding that HP will announce an upgrade path
to a multi-processor PA-RISC machine for a future generation of PA-RISC.
Unfortunately, Apollo HP is uncertain as to whether the multi-processor
PA-RISC will fit into the present Series 10000 cabinet.  There are vague
assurances about trade-in value, but I fear the return value will be no
better than 40 cents on the dollar.  In other words, if PRISM II had been
more ambitious, then the disk, disk controller, memory boards, ethernet
interface, and power supplies would have remained useful.  To say that an
upcoming PA-RISC may or may not fit into the cabinet is to say that all
those other parts may or may not be of much value.
   Traditionally, Apollo has worked hard to give as much value as possible
to the customer.  The software enhancements and equipment upgrades have
often benefited owners of already installed workstations.  According to
sales brochures, Hewlett Packard is very much interested in quality and
protecting customers' investment.  It was understandable that during the
confusion of a buyout and merging of products, users might see some absurd
policies being proposed.  But now, the policies of HP are seen as indicative
of a long-term trend rather than the transition period.  Unfortunately, that
long-term trend is inimical to owners of DN10K's and to users of SR10 O/S.

Disclaimer: These are my opinions unless specifically attributed to
someone else -- even in the latter case, selective attribution reflects
my own biases.  Nothing herein reflects the policy of any organization.

scheinin@mrlaxb.mrl.uiuc.edu (Alan L. Scheinine) (05/02/91)

      Recently, I wrote:
 >   I sent a letter -- which in part is similar to the following text --
 >to Apollo about seven weeks ago.  I sent it to two people who knew me from
 >my beta-testing work, and to someone else who had replied to me previously.
 >I kept asking for a reply but got just two things: one insult; and from
 >another person (about a week and a half ago) a recipient who is very much
 >on the technical side rather than marketing, said that while he has no
 >control over policy, he would forward the letter to someone in marketing
 >who could answer it.  I've not heard anything more.

   Today I got a very nice email from one person to whom I originally
sent my letter, Mr. Paul Bemis.  There is a high probability that he was
NOT responding to the above complaint in comp.sys.apollo.  He wrote that
he had been on the road because of the launching of the HP 700 series and
just got back.  His reply was intelligent, friendly, and really useful.

   Now that I've got your attention.  In the long run, there will be OSF.
I think we need to push really hard for Domain O/S features and Display
Manager features for HP's implementation of OSF/1.  Write letters to HP
management.

Disclaimer:  These are my opinions.  Nothing herein reflects the policy of
any organization.
Alan Scheinine, Graduate Student   email: u10534@uy.ncsa.uiuc.edu
Loomis Laboratory of Physics       Phone: 217-333-1065
1110 West Green Street             FAX: 217-333-9819
Urbana, IL  61801