Index Home About Blog
Subject: Re: SGI slipping
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Nov 17 1995
Newsgroups: misc.invest.stocks,comp.graphics

Short version:
(Note: for context, while at MIPS, I was one of the people who helped sell
Microsoft on doing an NT port, I worked with them at various times,
spoke at Microsoft sales meetings, have demoed NT on MIPS-based hardware,
etc...  I have even played with an SGI Indigo running NT, and at least
know one of the engineers SGI sent up to Redmond to help get OpenGL into NT.
I.e., while an old UNIX guy, I am not an anti-NT bigot.
Most SGI machines have the necessary machinery to support Little Endian
byte order needed for NT.  )


In article <30A40F90.41C6@cell.cinvestav.mx>, Heinz Hemken
<hhemken@cell.cinvestav.mx> writes:

|> Also, a question for Mashey and SGI: what about confecting a hardware
|> abstraction layer for NT to run on standard-issue SGI machines? This
|> would effectively neutralize the problem. NT from Indy to Power
|> Challenge would put SGI at the top, the middle, and the bottom of the
|> market, a major killing indeed.

Q: Given my comments above, why can't you buy SGI's running NT?

A: Because *no one* could figure out how *SGI* can actually make money
doing so.  I hope it is obvious that serious people thought pretty
hard about it...  This is especially clear at the *bottom* of the
product line, i.e., where SGI would be reduced to engineering graphics
boards and drivers to go into PCI-based off-the-shelf systems.
Most of the desktop machines lose capabilities, and the high-end
machines simply disappear (they have characteristics completely
outside NT's space.)

LONG VERSION FOLLOWS


Q: Why is that?
A: At this level, NT is a commodity-style business.  Hardware companies
who sell PCs spend 2% on R&D, and make money by selling large volumes.
SGI spends 10-13% on R&D, and makes its money by:
        a) Innovating in various areas, and making tradeoffs and tuneups
           across both hardware and software.
        b) Producing solutions that are *worth* more than the raw costs of
           commodity parts, at least worth it to somebody.

The posting above in fact illustrates the problems:

1) Power Challenges(& Challenges):
        a) Run full 64-bit operating systems; in fact, a great deal of
           our product line is shortly due to switch to this.
        b) Have various internal scheduling, and various other software
           derived from supercomputers.
        c) Support up to 16GB of main memory; we've sold some like that,
           and certainly a bunch on the 4GB-8GB range.
        d) Support a 64-bit file-system that has been clocked at 300MB/sec
           for reading/writing a single file.
        e) Handle up to 18 (36) CPUs; we've sold some like that, and have also
           sold gangs of them (Power Challenge Arrays) that work together
           on big number-crunchers.
        f) Have a number of systems in the field with 200GB DBMS, some in
           progress towards 400GB, and some in progress in the 1TB range.
        g) Support massive tertiary-storage robots, etc.
        h) Has very good NFS V3 performance.
        h) (and a whole bunch of other characteristics).

In fact, it might be possible for there to be a HAL that might support such
machines  (at least, the R4400-based Challenges, the R8000-based Power
Challenges might have some awkward internals differences)
 ... but unfortunately, of the characteristics described above,
exactly ZERO (0) are supported (or sufficently supported) by NT ... hence
a whole lot of SGI revenue just disappeared by changing UNIX -> NT.
(BTW, there is a difference between theoretical support, and actually
selling this stuff and having it perform well).

Some of these deals were won by outperforming other vendors on
DBMS codes, for which one reason was serious OS tuning.

Note: none of these comments are derogatory to NT: I just want to point
out that the characteristics that let these machines win deals go across
both hardware and software, and that the very approach of NT tends to make
it aim towards characteristics common across {Intel+some RISCs},
which among other things, means 32-bittedness, even on 64-bit hardware.
Put another way: it is a reasonable business model to sell hardware
tailored to run an off-the-shelf binary OS that comes from somebody
else ... but then you live exactly within the confines of that ...
regardless of what *some* customers want.  You usually do not compete
on engineering in that model, and in fact, may well buy much of your
hardware elsewhere, and concentrate on distribution, support, etc.

The other model is to focus on innovation, tight relationships with
leading customers, and building overall systems that can do other
things.  It is always true that if you spend a lot of money doing
engineering, and are no better than a commodity, you lose ... hence
you must always strive to keep ahead.  The second model thinks you
sometimes employ PhD chemists to work with certain customers,
and sometimes have very senior technical people spend serious amounts of
time with customers trying to do things they can't now. This model also
thinks that your OS people sometimes spend time making sure a 16GB machine
works ... even if we only sold a few of them ... and of course,
such economics make no sense at all for Microsoft.

2) Of course, SGI Onyxes are even worse off under NT, so scratch them also.

3) Power Indigo2s drop out (R8000s).

4) Indigo2s, Indy's, Indigos ... might be doable under NT, although
as I recall, at various times there were *not* NT APIs to get to some of the
features of these machines ... and *that* means that the features add
cost for no benefit, so in fact, those features would tend to drop
out ... meaning the machines themselves head towards being commodities.
(For instance, it seems unlikely that an Indy destined for NT 2 years
ago would have had a video camera, video-in, the audio, stero-glasses port,
etc.)  Even if you ignore those, there is still the issue of having
Extent-Based File Systems, heavily-tuned NFS V3, etc, etc. 

So, if they are headed towards commodities, maybe what SGI should do
would be to buy some of the NEC MIPS boxes, cut the SGI graphics down
to PCI (and accept the restrictions), and sell that ... just as
various others might do, but where the *only* differentiation left for SGI
is to build a graphics board and drivers ... and of course, there are
plenty of people doing that already.  MIPS boxes for NT have much more
in common with PCs and use PC components, than do SGIs, and for
good reason.

5) Of course, all of this is talking about machines whose basic
designs were done several years ago.  SGI builds a design, then
does CPU upgrades and graphics upgrades, and sometimes I/O upgrade,
so that people can partially upgrade their systems over a few years.
You might possibly guess that new designs are coming (and of course,
I cannot say when, or what they are.)  I *will* say that some of what's
coming is *even further* outside the NT design space than the
Power Challenges described above.


===
So anyway, it's not for lack of thinking about it...


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-933-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Subject: Re: SGI slipping?
From: mash@mash.engr.sgi.com (John R. Mashey) 
Date: Dec 07 1995
Newsgroups: misc.invest.stocks,comp.graphics,mex.red,mex.general

In article <30C247EA.167E@cell.cinvestav.mx>, Heinz Hemken <hhemken@cell.cinvestav.mx> writes:
|> John Mashey of SGI had the following to say:
...
|> 1) Power Challenges(& Challenges):

|>      d) Support a 64-bit file-system that has been clocked at 300MB/sec
|>        for reading/writing a single file.

I'm requested to fix this: 480MB/sec from one file these days, 540MB for
multiple files. 

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-933-3090    FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Index Home About Blog