[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UX400S product backgrounder
[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
Date: Thu, 10 Aug 89 19:05 EDT
From: barmar@Think.COM (Barry Margolin)
Date: Thu, 10 Aug 89 15:08 CDT
From: firstname.lastname@example.org (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
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
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.