Re: UX versus standalone

[dmitchell@BACKUS.trc.amoco.com (Donald H. Mitchell)]

    Date: 18 Jul 90 17:17 +0100
    From: "(Marc Riese)" <riese@litsun.epfl.ch>

    Don,

    My lab has been considering the purchase of a UX400S.
    Can you spare a bit of time to tell me briefly whether you are happy
    with yours as compared to a stand-alone Symbolics?

Very happy.  The maintenance costs are low, I can use my Symbolics, my Sun
X-windows applications, and my mainframe from the same keyboard and screen.  I
can run the Symbolics from any Sun in the building (rather than having a
dedicated monitor).  I store all my files on a Unix fileserver so the Unix
system administrators handle all the backups and disk administration.  I use
the Unix printers; so, I don't have to have any for the Symbolics's.  I use
the Suns's tape drives; so, I don't have to have any for the Symbolics's.  The
UX is faster than the 3640 that we used to have, it doesn't make any noise,
etc.  When I put orders through for the UX, I call it an accelerator board for
the Sun; so, nobody complains about introducing new processors into the
building.  No one coming into my office can tell that I have a Symbolics: a
definite advantage in my environment.

    Do the advantages outweigh the disadvantages?

For me, yes.  However, I would never buy a UX unless I already had the Suns.

    As I understand it, the major arguments in favour of a UX are that
    it costs less than a stand-alone, and it can interact to a certain degree 
    with Sun/Unix applications (with limits such as you mention).

And you don't need yet another computer monitor in your office (I know people
around here for four monitors so they can connect to four separate computers.)

    I know little about it so far, but for me, the disadvantages seem to be 
    that the UX is young and probably has a lot of compatibility problems,

None that I've found other than minor misunderstandings and some slips by
Symbolics when considering the UX (Oh, we never thought about someone having
only UX's).  They usually can get me around these problems.

    and I'm worried about its effect on the rest of the system.

Pretty minimal from the CPU, packets, interrupts, etc.  Most impact is on the
disk as you page memory and load files, but it wouldn't be any different than
having another Sun using the host as a fileserver.  The most awkward thing
really is having to re-load everything everytime the Sun host re-boots.
Second is trying to reset the UX without re-booting the Sun.  I've never
successfully done that.  I usually reboot the Sun.  But, if the UX was in a
fileserver perhaps with other UX's (the configuration we're going to this
fall), you can't reboot all those processors just because the one UX gets
wedged.  The force boot usually works, however.  I could probably count on one
hand the number of truly wedged states (forcing board reset rather than just
re-initing FEP) and I've had one UX for almost a year.

    We have a Sun 3/470 server that can handle a UX according to Symbolics.
    It is powerful, but how badly does the UX decrease its performance
    for other users? 

As I said, barely more than just another Sun using it as fileserver.

    How many diskless Suns can be connected to it before
    performance dies? One? Ten? I realise that this depends on a lot of factors,
    but any educated guesses, blatantly subjective comments, whatever, are welcome.

Connected to what?  The 3/470?  I don't know, ask Sun.  The UX?  Diskless
doesn't matter in that case.  We've had upto three people simultaneously using
one UX.  You can really feel the degradation.  If everyone is just editing
files, then the system hums along until someone saves or visits a new file.
If someone compiles a file, then performance decreases by 30-50%.  That's
without trying to do any system administration to reduce priorities of those
things.  There are a few programs that don't work correctly if more than one
person is using the UX.  Usually what happens is that these programs start on
the console window of the first UX user no matter who initiates the programs.
Examples include the namespace editor and the inspector.

    Sincerely,
    Marc Riese

Don Mitchell			dmitchell@trc.amoco.com
Amoco Production Company	(918) 660-4270
Tulsa Research Center
P.O. Box 3385, Tulsa, OK 74102