Return to ING home page5. Technical risks

This page is part of the ING manual INS-DAS-23 Architecture for UltraDAS.


This section is copied unchanged from issue 1.1 of the ADD, which was written before UltraDAS was constructed; hence the use of the future tense and the general air of anxiety. The risks were contained successfully in system s9, but they remain relevant should the system be revised in any significant way.
The chosen architecture inherits many proven design-patterns, but it also introduces new elements of design and is forced to reuse some patterns that have given problems in the past. This section lists the major risks that the finished system might not work satisfactorily. Risks that a working system might be delivered late, and having cost too much, are not considered here.
 

Hard limits on readout speed

If the fibre-optic interfaces to the detector controllers do not have enough bandwidth, the controllers must be detuned to less than the best rate that the detectors can deliver. This problem is discussed in section 6 and we have these findings:

Loss of pixels through DMA failure

If the buffer memory in the PCI interface overflows, pixels are lost. This could happen if the transfer of pixels from the buffer across PCIbus to SPARCstation memory does not keep up with the input of pixels from the camera. It is hard to guarantee this real-time performance on Solaris; doing so limits the form of the acquiring programme quite severely. UltraDAS makes no special concessions to hard real-time input, but assumes that there is enough buffer memory on the camera-interface board for an entire readout; UltraDAS always waits for the buffer to empty between readouts.

There are two sizes of buffer memory in the interface boards. The standard board has 16 Mwords which is enough to store one frame from an EEV42 or one exposure from INGRID, but not enough to store an observation from the INT WFC mosaic. The larger board, to be made specially for ING, has 96 MWord of memory and the planned combinations of these boards will store one readout of any planned camera.

Initially, both single-chip cameras and INT WFC will be run with the standard interface. Hence, INT WFC could overflow the buffer either randomly or systematically. A prototype should be made to check that this does not happen.

Bottlenecks in the disk system

The throughput required of the data discs is discussed in section 6. To exploit this throughput, the DAS server-programmes have to run efficiently.

Tests in Cambridge suggest that the I/O performance can fall off badly for large images if the DAS computer is short of RAM. The system may slow down by three or four times. More prototypes and tests should be carried out to find how much memory is needed to prevent this.

The most critical test is to determine the speed at which data can be written to a single partition on DASAN.

Preprocessing of images

The IR cameras require preprocessing of the data in memory before writing it to disc. For UltraDAS, this means that the preprocessing is probably going on in parallel with writing to disc. The implications of this on memory usage and other system resources need to be checked. There is a danger that the cycle time will get to be too long.

PCI interface

Both the hardware and the software for the PCI interface are produced by SDSU. There is a danger that vital functions will be left out initially and cannot be added later because ING does not have full knowledge of the design or does not possess the source code. To avoid this, a protoype of the server applications should be built to reveal the need for any obscure functions.

Communications overhead

Long communications delays between the clients and servers or between the servers and controllers could spoil the efficiency of the system. Both interfaces should be prototyped as soon as possible.