Experiences with 4D/2xx as timesharing systems?

[Jim Barton]

In article <89Apr9.160219edt.38129 at neat.ai.toronto.edu>, rayan at ai.toronto.edu (Rayan Zachariassen) writes:
> Our major worry (in the fine SGI tradition...) is with the software, in
> particular we consider any System V based box to start out with a negative
> (this is our reality not our religion).  We understand SGI is committed to SV.

Sounds like religion - for SGI it's commercial reality, as it is for every 
other successful computer vendor.  Oh well, why tilt at windmills?

> Does this mean they will track AT&T SV releases directly, or that whatever
> SV-based OS that MIPS comes up with will shortly appear on the 4Ds?

IRIX != UMIPS.  We are committed to tracking AT&T releases.  IRIX currently is
at V.3.1, with V.3.2 late this year.  We will implement V.4 as expediently
as possible.  We will also consider any major OSF/1 feature which adds value
to the system.

> The filesystem is a worry.  We're happy it isn't SV but unhappy at the
> apparent gratuitous incompatibility with the BSD F^nS.  Our tools are
> unlikely to work, right?  It also seems like a less robust design.  Will it
> go away in favour of something else that is largely compatible with
> F^nS ((Fat)Fast File System)?  I note that MIPS ships FFS with their
> rice-computer OS, how come SGI seems to be waiting for SVR4 to do the same?

Why worry?  The SGI ExtentFileSystem is >faster< than the BSD FFS.  For
instance, on the Jim Barton extra-special-whizzy single-and-multi-process
blow-out-the-buffer-cache benchmark (substantiated by the AIM II disk 
benchmark and other tests), UMIPS 3.0 FFS on the M/120 runs about 15% slower
than IRIX 3.0 EFS on the >exact same hardware<.  And we've put alot of work
into EFS since the 3.0 release ...  As to robust, it also duplicates
superblocks, has cylinder groups, bitmaps and the like, but it can use
>all< your disk fairly effectively (try that with FFS!)

I'll be happy to send you a copy of the benchmark, as well.

> During testing on the personal iris, some anomalies showed up that could
> be explained by the scheduler or VM being tuned for a single-user workstation
> environment.  For example running a certain (non-graphics) program would
> cause lost ether packets and horrible response time on the iris, but the
> same program is apparently wellbehaved on other machines.  Similarly, logging
> out of the PI causes lost packets.  Anyone experienced similar anomalies
> on the 4D/2xx?  Anyone using them for timesharing?

Main problem is with the window manager, which is pretty heavyweight.  For all 
that nice display and all, it takes lots of memory, which has to be fought
over with the application you are running in a limited memory system.  If
you really aren't interested in graphics, don't start the window manager,
and the performance will be very good (you >said< server, right?).  Try
running your same application on a Sun 4 with NeWS and 8Mb of memory (assuming
you can get Sun to sell you one) and amuse yourself with the results.

As to the lost packets, I believe that this bug is fixed in the latest
release available to the field.

> How does the fine-grained multiprocessing support (threads libraries, compiler
> support etc.) differ qualitatively from other implementations (MachOS,
> Sequent, Encore, Sun)?

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.

> Can one use a 4D to serve root and swap for a SunOS 4.0 workstation?

I assume so.  We are currently at NFS 3.2, so if that's all it needs, it
should work.

> How is the hardware reliability on the 4Ds?

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

> Any other pertinent comments from customers are welcome.  The kind of
> configuration that is of interest is a 4D/240S with minimal extra stuff
> (small SCSI, cartridge), to which we'll add the storage subsystem w/ a
> few gigs of disk.  Users would have access via the ether.  In the
> timesharing application we would want to potentially support at least
> twice the work our Sun4/280Ss are being asked to do (which is 30 users
> + 30 workstations, mostly light activity but occasional developers and
> long-running and/or large jobs) which it does well when it works.

You may want to buy the storage from us.  We currently support >10Gb of
storage on a single machine through large-capacity SMD drives.  Since 4
processors with twice the power of a Sun 4 are in the same box, I would
think the load you describe would be easily handled.  In my lab, we use 
a 4D/120 with 2 extra processors (an "unofficial" 4D/140).  We have a
150Mb SCSI cartridge, 9-track, E-net, etc.  The disk configuration, from
/etc/motd, is:

Maddog 4D/140S  IRIX 4D-3.2A (Alpha 7)
ASD Compute/File Server

===============================================================================
CDC Sabre 9720-1230 1.2Gb SMD  xyl1d1s0	/
                               xyl1d1s6	/usr		build tree
Fuji Eagle 2351	    400Mb SMD  xyl1d2s1	/usr/tmp
                               xyl1d2s6	/f		user data
Toshiba MK156FB	    156Mb SCSI dks0d1s7	/e		MIPS source
Fuji Eagle 2351	    400Mb SMD  xyl1d0s7	/d 		user data
Hitachi 514-38	    380Mb ESDI ips0d3s7	/g		user data
Hitachi 512-17	    150Mb ESDI ips0d0s7	/vme0		BRL, MIPS bench
Hitachi DK514C	    380Mb SCSI dks0d2s7	/vme0/jmb/other	user data
=======================> 3.1 Gb and counting <=================================

This machine is used by > 30 workstations and lot's of users, performs as
a build machine, as well as supporting our development environment, with lots
of NFS filesystems, constant E-net traffic and more.  Since a 4D/240 is twice
as fast as this machine, you should have no problems.

> Please REPLY BY MAIL!  I will summarize if interesting info appears.

I thought the net might be interested in the quasi-official SGI answer.

> Thanks,
> 
> rayan
> 
> AI/NA/Theory, DCS, U of Toronto

My pleasure.

-- Jim Barton
Silicon Graphics Computer Systems    "UNIX: Live Free Or Die!"
jmb at sgi.sgi.com, sgi!jmb at decwrl.dec.com, ...{decwrl,sun}!sgi!jmb

  "I used to be disgusted, now I'm just amused."
			- Elvis Costello, 'Red Shoes'
--