There are three main locations where computing devices are installed. All are interconnected by various speeds of Ethernet at the moment.
For this discussion, anything installed on the telescope itself, whether at Prime, Cassegrain, or even Coude is all considered ``Telescope.'' [Though this might be a good place for some discussion of differing connection facilities at each?] Only hardware which is required to be near the instrument is installed here. This includes hardware to control power supplies and monitor auxiliary electronics, and the detector controller for the camera itself.
Locations on the telescope, such as the prime focus, are wired with Ethernet. It is possible to connect a portable computer to have limited access to the instrument. Small ``network appliances'' (I-Openers) are also currently installed at locations on the telescope to transmit images from sky-monitoring camera cameras.
Ethernet is also used to connect remote diagnostic units like the BayTech ``MDAC'' which provides a route to Serial connections for other hardware and control of power sources. Units such as this can also be used to acquire basic data (voltages, temperatures, etc.) at points near the instrument. RS232 and other serial connections are commonly used by devices on the telescope, but it is possible to tunnel them through the Ethernet, or through fiber in the case of MegaCam's controllers. This simplifies error correction and virtually eliminates distance limitations.
MegaCam uses a detector controller designed at the C.E.A. in France by Jean de Kat, which is based on Analog Devices' ``sharc'' DSP. This new controller handles the high readout speeds of MegaCam. The guide CCDs for MegaCam use the San Diego State University (``ARC'' generation II) controller.
Currently, all our other controllers are also the SDSU II type, by Bob Leach. These consist of a set of boards providing the analog and the digital functions, and are based around the Motorola 56000 Digital Signal Processor (DSP).
A final controller for WIRCAM has not yet been determined, but an SDSU generation III controller is currently being used for characterization and learning about the new Rockwell detectors/multiplexers in the lab in Waimea.
All controllers currently use fiber optic links to send pixel data down to the 4th floor computer room.
Below the telescope, on the 4th floor of the building, is a climate-controlled computer room. It houses two important computing hosts for data acquisition: the Detector Host and the Session Host.1A third host, the Display Host is located outside the computer room and close to the screens which it drives, for logistical reasons.
The fiber carrying the pixel data from the instrument connects (via a nearby patch-panel) to an interface on a Detector Host's PCI bus. (This is true for both SDSU and MegaCam controllers.) The main function of this host is to reliably read out the detector and provide the data in FITS format to the Session Host. Redundant hosts exist mainly for backup, though it is conceivable to use multiple detector hosts at once.
For infrared acquisition, the Detector Host may perform more complex tasks, such as co-adding frames and performing calculations for on-the-ramp integration. (It is preferable to us to do these tasks on a Unix host than on a DSP.) Each host will be configured with sufficient memory and local disk space for these tasks. If possible, the local disk space should be sufficient to also take over the functions of the Session Host (see below) for a full night in an emergency. Thus, if everything save what we have described so far were to fail, it is still possible to do a lot with just the detector controller and the detector host. In a lab setting, this is often the normal mode of operation. It also means our engineering interfaces are not radically different from our observing interfaces. [NOTE: This mode is not practical for the Queue Scheduled observing mode we use with MegaCam. Instead, we make sure that down-stream hardware of the Detector Hosts are also redundant.]
The Session Host runs all other acquisition software and user interface components. Images are transferred across either a 1 GBit switch for MegaCam, or 100 MBit switch for other detector systems. An alternative to the Detector and Session host could be one computer, but since the Session Host also houses the RAID disk storing most of the data and experiences more unpredictable bus loads, there may be complications with that approach. The Gigabit Ethernet solution has already been shown to be one viable option, and is currently being used for MegaCam (and most of the data reduction network at this time.)
As the image is read out from the array by the Detector Host, it is simultaneously copied to the Session Host over the Ethernet Link, and is therefore both on disk, and cached and ready for fast image display by the Session Host within seconds of the end of the readout. Instrument control and high level sequencing may also be handled by the Session Host. Any quick data evaluation required by observation and needing fast access to the data may run here as well, but for MegaCam, separate real-time elixir systems exist for this purpose but in Waimea and at the Summit. The Session Host is the computer with which the user has the most interaction.
The Display Host for the observer runs a multi-headed X-Server. No other processes run on this machine. Hard drives may or may not be present in this machine. If they are they will only be used for temporary or local swap space. The network speed requirement for this host will never exceed the needs of X11 traffic to update the screen. Three flatpanel screens, currently 1600x1024 pixels each, connect to three digital-output video cards in the Display Host. A single keyboard and mouse controls all three as one virtual screen of 4800x1024 pixels. (More on this in a later section.)
A high bandwidth network (DS3) connects the Summit and Waimea computing facilities.
In Waimea, an identical display host is located in the Remote Observing Room. Once again, all processes displayed here run far away, on the Session Host at the summit. A method to duplicate the contents of Summit Display Host's screen in Waimea (Virtual Network Computing) has been explored, but the approach of making each control interface capable of having multiple instances is being favored. Such a solution is currently being used for both graphical (X11 or Web based) and command line interfaces. Like the Summit Display Host, the network speed and latency needs of this Remote Display Host are limited to screen updates, and are already met by our DS3 network.
