Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!adt.UUCP!madd
From: madd@adt.UUCP (jim frost)
Newsgroups: comp.sys.sgi
Subject: Re: Experiences with 4D/2xx as timesharing systems?
Message-ID: <8904111520.AA05578@adt.uucp>
Date: 11 Apr 89 15:20:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 48

>In article <89Apr9.160219edt.38129@neat.ai.toronto.edu>, rayan@ai.toronto.edu (Rayan Zachariassen) writes:
>>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.

DEC?

Seriously, not every vendor who supported SysV was successful, nor
(more to the point) does every successful vendor support SysV, even
throwing out those companies who don't care about UNIX at all.  Most
of the very successful vendors support SysV but add a lot of the BSD
functionality -- job control and sockets are the biggest ones; almost
everything else just affects performance.

>We will also consider any major OSF/1 feature which adds value
>to the system.

I don't think you'll see anything in OSF/1, which is going to be
pretty vanilla IBM AIX; OSF/2 is supposed to have a lot of new
functionality but that's vaporware for awhile.  I'll be surprised to
see OSF/1 out before this time next year no matter what the official
word is.

>The SGI ExtentFileSystem is >faster< than the BSD FFS.

Could we get some info on your benchmark?  I'm particularly interested
in how each FS was tuned.  I tend to believe the results considering
the FS throughput our SGI's have, but tuning can be everything.  I'd
also like to know what you do to keep fragmentation down when the FS
fills up; I'm curious.

Our biggest complaint about SGI performance is that it degrades
substantially over time.  I'm fairly certain that this is a VM problem
since it happens with every large application I've run, including some
which have pretty clean usage and do *not* have this problem under 4.3
BSD.  The system returns to its former spunkiness after reboot.  I
might expect that it's related to 4Sight except that logout/login
doesn't correct the problem.

Speaking of 4Sight, it would be very useful to some people if SGI
would provide a method of accessing graphics without the window
manager.  4Sight eats up a lot of memory ("heavyweight" as you say) as
well as some graphics resources (particularly bitplanes) which
applications could make use of.

jim frost
madd@bu-it.bu.edu