UX400S product backgrounder

["Gary M. Palter" <Palter@STONY-BROOK.SCRC.SYMBOLICS.COM>]

[Please take some of my statements with a grain of salt.  I wasn't
heavily involved in the UX400S project and may have made some incorrect
statements here.]

    Date: Thu, 10 Aug 89 19:05 EDT
    From: barmar@Think.COM (Barry Margolin)

	Date: Thu, 10 Aug 89 15:08 CDT
	From: dmitchell@backus.trc.amoco.com (Donald H. Mitchell)

	In particular, my deskside 4/110s (three of them) each have an extra 9U
	VME bus slot.   I can buy SCSI disks and tapes for these if necessary;
	however, I would love to avoid it and have the Symbolics page over
	Ethernet (I know about speed problems).  Symbolics, however, does not
	have 4/110's in its shop; so, they are reluctant to sell boards for
	them.  My questions to the net are how many others would be interested
	in 4/110 support? Does anyone see a compelling reason for a local drive
	and tape?  Should there be a technical reason the 4/110 won't work?

    I'm just guessing, but I suspect that the UX400S will require TWO 9U VME
    slots -- one for the processor board and the other for the memory board.

You only need one slot for a UX400S.  The processor board has either 2MW
or 4MW of memory on the board.  If you order an optional memory
expansion board (2MW, 4MW, or 8MW), you'll need a second slot and it'll
have to be adjacent to the processor board's slot.

We are reluctant to sell machines for a configuration that we haven't
actually tested.  In our development, we've found that each Sun has
subtle differences that can affect whether or not the UX400S will work.
I don't know what our policy is w.r.t. selling UX400S boards for
inclusion in machines we haven't tested.

Theoretically, one could put a UX400S into a diskless and tapeless Sun
but we've never actually done it.  I know that we've mounted FEP
partitions on remote systems using NFS and have loaded worlds across the
network.  I don't believe that we've tried to use paging files on a
remote FEP partition so I can't say what performance would be like.
Perhaps one of the UX400S developers will comment on this issue.

	I also have a SparcServer 390 on order for which I will not have a
	workstation terminal (just a RS232 dumb terminal and lots of file
	service clients running X).  This fine beast has 2 GigaBytes of disk and
	a tape drive; so, it passes those requirements.  However, because it
	does not have an X terminal directly attached, I'm not certain it will
	work for an embed board.  The Symbolics board would have to have
	something in its FEP telling it that its X device was whatever server I
	choose (statically or dynamically).  Does anyone see a reason this use
	of a remote X server wouldn't work (since X by definition supports
	remote)?  

    I think this should be able to work.

I'll leave this question to the UX400S staff.

		  Does anyone see why you couldn't put more than one Symbolics
	board into this type of machine (it has somewhere between 9 and 13 9U
	VME bus slots available)?

    There was some discussion along these lines recently about doing this
    with the XL400; since the UX400S uses basically the same board as the
    XL400 (the board is called "Merlin", I believe), the answer should be
    the same.  

Merlin is the name used for the board set; there is no one board known
as a Merlin board.  In other words, both the XL400 and UX400S use a
Merlin processor board.  The XL400 also includes a Merlin I/O board.
Both systems will accept an optional Merlin memory expansion board.

	       I believe the problem was that all Merlin boards are
    configured with the same VME bus address.  There IS a way to change the
    address (they needed it so they could use one Merlin to test another),
    but I don't remember whether it is as simple as DIP switches or whether
    it requires replacing a chip.

Changing the bus address requires replacing chips.  There are no DIP
switches on the processor board.

    An issue specific to the UX400S is the communication between the host
    processor and the coprocessors.  The host software may not be designed
    to deal with multiple coprocessors on the bus.  (Not having actually
    seen a UX400S, I'm going to be making some assumptions about how the
    host communicates with the coprocessor -- specifically, that it uses a
    device driver.)  The standard VME address might be hard-coded into the
    device driver, for instance.  To allow for multiple coprocessors they'd
    need to arrange for the minor device number to be usable to select
    different VME addresses.  Then you could start up multiple copies of the
    host software, telling each one to use a different device.

Your guess about a device driver is correct.  Your guess that the VME
address is hardcoded is incorrect.  The driver is designed to allow
multiple processor boards.  However, we've never tried such a
configuration and I strongly urge that no customer try it on their own.

						    barmar