Summary of Re: Experiences with 4D/2xx as timesharing systems?

[Rayan Zachariassen]

[ anything in "'s are quotations from private responses, anything in >'s are
  quotations from the info-iris list.  ]

SGI will follow market pressures as to their OS base.  [ Someone should
consider this as market pressure... ]

SGI does not track MIPS OSs, they do track MIPS compilers.

SGI is working on Berkeley style sysadmin tools, per request from customers.
[ :-) ]

The lost packet problem should be fixed in the 3.2 release out this summer.
Seemingly it has to do with DMA contention problems when the graphics
subsystem and the ethernet butt heads.  The fix involves both hardware
and software.

If the Gods are willing and the moon is in the right phase, Sun diskless
client support is supposed to be released with the 4.0 OS (I assume this
means the SVR4 base).  However it is apparently quite possible (i.e. it has
been done) to run a diskless client right now as long as it can get its
boot information from a Sun somewhere on the network.  The major stumbling
block for SGI to provide this support are administration (i.e. handholding)
and logistics (i.e. how the heck does one read a Sun tape onto an SGI box :-).
(which, incidentally, is a good real question...)

"We publish a demonstrated MTBF number for all machines.  PowerSeries
 products are rated for at least 6000 hours."

Fine-grained parallellism:

"The lightweight process stuff was modelled after the work at several
 other companies, including Cray, Sequent, and work at Argonne.  We
 haven't had any complaints about it.  And the parallelizing Fortran
 compiler uses it easily.  C programmers use it with great success, too."

"Its better, of course! :-).  The thread implementation has been published in
 USENIX proceedings, etc..  It provides a much more natural model for multi
 threaded applications than any other model I know of.  We also support
 a layer of synchronization using spinlocks and semaphores that religiously
 avoids kernel interaction.  Remember that syncrhonization latency is the
 chief problem in getting high performance from fine-grained parallelism.
 On top of this are some of our primitives, plus the Sequent m_* routines
 for simple parallel programming."

"In the environment, we support a multi-process asynchronous debugger which
 works on normal and "threaded" processes (Sun, Mach don't!).  The profiler
 handles a threaded process correctly.  All this is integrated with the normal
 high-performance MIPS compilers."

Filesystem:

... the barrage:

"The filesystem is quite fast and quite reliable for us."

"Why worry?  The SGI ExtentFileSystem is >faster< than the BSD FFS."

"Why do you care what the filesystem format is like, as long as it
 is fast and reliable?"

"EFS may seem gratuitously NIH, but it beats FFS on comparable disk/controller
 combinations.  Its reputation may be due in part to the lack of a good fsck.
 EFS's fsck is derived from SVR0's!"


It is totally irrelevant to us that EFS may be faster better stronger.
It is different.  We care because we have tools that know about the
(BSD) filesystem.  We *HAVE TO* port some of those tools to any SGI box we
would use for timesharing.  Because the filesystem is *different*, the
porting complexity goes way up.  If EFS is better, wonderful, it is
good to know its there if we need it and are willing to pay the price,
but it shouldn't be foist (or forced) upon us.

In response to that:

"You might find that your tools will have difficulties poking around
 in super blocks and so forth on any machine except the original on which
 they were developed.  Even in the most standard ... file system, ...,
 there are plenty of variations in the shape of things."

Yes, this is true to a certain extent.  However the differences will be
at user-level and will be relatively easy to circumvent -- plus the knowledge
base (in people) doesn't need to be updated.


Miscellaneous:

> 'tar' is not a backup program, no matter who thinks so.

Nothing that goes through the filesystem (tar, cpio, bru) is an acceptable
backup program in a large installation.

> The filesystem does not appear to be BSD FFS, something which
> becomes an issue real fast with a lot of users.

Only if the not-FFS filesystem is the V7/SV filesystem.  Our concern
is not that it is slow (lots of people assert it isn't).

> If you use Sun's yp, you're in for a lot of fun.

Yah, which is why we refuse to use it on our Suns.

"Higher ups at SGI do appreciate how competitive the 4D/220 and 240 are
 as computing engines.  ...  We regularly beat Alliant, Ardent, Convex,
 and Stellar."

All these boxes are "computing engines", dedicated to a few people at a
time who do their own maintenance and put the box beside their desk or
in a closet nearby.  SGI machines are getting interesting in another market,
the one that used to embrace the VAX780, then the Sun3/280 and the Sun4/280
(gosh, I guess the next decade will see '90-suffix machines on top :-) for
general purpose timesharing.  The needs of this market are different.
Software needs to fit into a pre-existing environment, hardware should fit
into a rack (that's a hint...), decisions are made based on lots of factors
that are irrelevant to the guy who wants fast graphics.  It is a "professional"
(in the positive sense of the word) systems environment, with competent
technical support.  Priorities are different when you have to provide a
reliable and useful computing service to hundreds or thousands of people.
My impression is still that SGI thinks of itself as a workstation company,
and I really wish it would recognize this one of its opportunities (and if so,
let us know).

"I guess it's also the assumption that since we went standard we don't have
 any BSD compatibility.  We have lots, except for the system administration
 end of things."

Guess who makes the purchase recommendations ... (ex-)sysadmins.  In every
market.  The more BSD environments you sell or can sell into, the more
important it is that "administration" (booting, accounting, spooling, etc)
looks like BSD, for that market segment at least.


I replied to everyone who sent comments and thanked them privately.
Here is a Thank You in public.  I only lament that noone responded who
was in a similar situation as us; are we really the pioneers?  Most
of the respondents were from SGI... the openness, responsiveness, and
enthusiasm of the SGI people reading info-iris is one of the reasons
we are interested in their products.

My conclusion: if we (or someone in our situation) can hang on until
SVR4/IRIX4.0 comes out, then it should be ok after that (not that we
won't still yell for complete future 4.xBSD compatibility :-).  Until
then it will be a hard road if we decide to take it.  SGI people seem
convinced it will be a rewarding one in the long run (err, rewarding
to both parties ;-).

rayan