2 OVERVIEW

The functions in the dxf module are designed to transfer large amounts of data between processes in the VLT distributed control system. A typical example is the transfer of data between an LCU interacting with the detectors and instruments, and a WS where the data is possibly stored or visualized for the user. The dxf functions provide the services for sending and receiving the data over the given communication channel, possibly using compression. Compression should only be used if the communication channel is very slow.

The possible environments in which the dxf could be employed for exchanging data are:

2.1 THE PROTOCOL FOR THE DATA EXCHANGE

The Header Data could typically be FITS header information or other administrative information. This kind of data is sent with maximum one call to dxfSendData(). This data can only be send uncompressed.

The actual detector data to be transmitted. The data can be sent with one or several calls to dxfSendData(), compressed or uncompressed.

2. The sending process receives and checks the request, and if the request is identified as a legal request, the dxf function dxfSendData() is called with the parameters in the structures for the Header Data, the Data and the Trailer Data defining the transfer properly set. Data can be sent with several calls to dxfSendData() or with one call. The optional Header and Trailer Data are always sent with maximum one call to dxfSendData(), whereas Data can be sent in one batch or as individual batches.

3. The receiver calls the dxf function dxfRecvData() to start the reception of the data stream. The function handles the necessary buffers in which to store the data received. It is up to the calling application to make local copies, since data will be overwritten by the next call to dxfRecvData().

dxfRecvData() can be asked to return all data for the transfer or to return the 3 data types individually. The data itself can be returned in one batch or as individual messages.

When each of the three batches has been received by dxfRecvData(), the "done" flag in the structures for the Header Message, the Data and the Trailer Message will become ccsTRUE.

It is left up to the designer of the applications using dxf to define a (simple) protocol necessary for initiating the data exchange. A predefined protocol is not defined and supported, since dxf is a multi-purpose data transfer tool, and there will be different needs for the various usages.

2.2 ABORTING DATA TRANSFER (SENDING AN ERROR REPLY ACROSS)

It is possible to abort a data transfer by setting the CCS Error Stack using the errAdd() function, and then use this error stack as input parameter to dxfSendData(). This function then sends an Error Reply across and resets this data transfer session and is thus ready for the next. After that dxfSendData() resets the Error Stack and returns with SUCCESS if the Error Reply was successfully sent. Otherwise it returns with FAILURE and the Error Stack properly set.

On the receiving side dxfRecvData() receives the Error Reply, resets itself so that it is ready for the next transfer, and returns the error sent from dxfSendData().

Note, that data transfers should always be aborted in this way, since otherwise the synchronization between the sending and the receiving entity is lost. An example of the usage of this, is the ABORT command. The user wants to abort the data transfer and issues an ABORT command. This is sent from the WS to e.g. an instance of the LCC Command Interpreter, which forwards the command to the sending process. The sending process sets the CCS Error Stack, and calls dxfSendData() to abort a data transfer currently on-going. Abortion of a data transfer is only possible when a data frame is sent as several blocks. If all data is sent in one batch, the transfer cannot be aborted. If the receiving process wants to abort the data transfer it must send off a command to do this in a similar way.

2.3 REQUIREMENTS TO THE OVERALL BANDWIDTH

In order to decrease the load of the network, or to obtain a higher transfer rate, the dxf module offers the possibility for compression of the data before transmission, and subsequently decompression at the receiving side. The compression is provided by subroutines and not by HW. Whether it is worthwhile to employ the compression feature depends on the speed of the computer and the bandwidth/the load of the network connection. If the computer has a very high performance, so that the extra processing of data due to the compression/decompression does not constitute a bottleneck, it might increase the overall bandwidth of the system to use compression, whereas if the network connection is relatively fast compared with the speed of the computers, the compression might decrease the overall bandwidth. It should be tried out experimentally if it is worthwhile to employ compression. For now only two compression methods are supported by dxf. These are a compression method based on the Lempel-Ziv algorithm yielding a relative good compression (dxfLempZiv()), and an implementation based on an unknown algorithm (dxfFinCompress() and dxfFinDecompress()). Both the compression implementations are somewhat slow for this usage. A comparison of the compression factor between the two implementations and gzip can be found in table 2.1. In table 2.1 one text file and four astronomical images are compressed. All astronomical images have 32 bit pixel representation. gzip was executed with the "-1" option yielding the fastest but (maybe) less efficient compression. As seen in the table, the compression factor may vary quite a lot depending on the image compressed, and the method used. Other methods can be introduced easily later on, if this is necessary. The functions for handling the overall compression/decompression of data are called dxfCompress() and dxfDecompress().


Data Type\Algorithm	dxfLempZiv()	dxfFinCompress()	gzip -1
Text File	0.47	0.65	0.33
Astronomical Image 1	0.99	1.00	0.83
Astronomical Image 2	0.81	0.75	0.51
Astronomical Image 3	0.65	0.60	0.42
Astronomical Image 4	0.31	0.38	0.25

Table 2.1: Compression factors for various types of data using various compression algorithms.

Some approximate key figures for the transfer rates within one WS, between two WSs, and from an LCU to a WS, are shown in table 2.2. The RTAP Q-Server was used. Data were transmitted both uncompressed and compressed. The compression algorithm used is the Lempel-Ziv based implementation. The transfer rate for the compressed data is constituted both by the time it takes to compress and the time for the actual transmission of the compressed data. The tests were carried out using HP-9000 WSs (99 Mhz), a Motorola 68040 based LCU (33 Mhz) and an Ethernet connection.


Environment\Condition	Transfer Rate Uncompressed (MB/s)¹	Transfer Rate Compressed (MB/s)
Data transfer within one WS	14.02	0.62
Transfer between two WSs	1.08	0.94
Transfer from an LCU to a WS	0.75	0.37

MB/s = mega-bytes / second.

Table 2.2: Key figures for the transfer rates with and without compression in three environments.

As seen, compressing the data decreases the transfer rate quite a lot. Especially transferring within one WS this decrease is large - the WS is occupied with compressing and decompressing the data at the same time. Needless to say, data should not be compressed while transferring within one WS. It should be mentioned, that the data used, were compressible to a high extent (to a size of about 10% of the original size).

Transferring between two WSs the transfer rate is about the limit imposed by the Ethernet connection. The transfer rates using compression between two WSs and an LCU and a WS are also quite poor compared to the case where no compression is employed. The conclusion for the compression feature as it is now is thus, that compression should only be employed in very special cases. This could for instance be when it is desirable to keep the load on the network low, and if at the same time the CPU time taken up by the compression/decompression does not constitute a problem. It could also be that it is advantageous to receive and save the data compressed to save disk space. It is foreseen to provide faster compression subroutines later on.

The transfer rate sending from the LCU to the WS is somewhat low. It also looks as though the LCU gets heavily loaded when compression is employed since the transfer rate for transmitting compressed is less than half the transfer rate transmitting compressed. The reason why the transfer rate from the LCU to the WS is relatively low, has still not been determined.

2.4 DXF BENCHMARK TEST PROGRAM

The November 1996 Release of the DXF contains a test script which makes it easy to test the transfer rate between two processes using DXF. The transfer can be done within one WS using one or two CCS environments, or it can be done between two WSs. The test script is called dxfBenchMark and uses the two test programs, dxfTestSend and dxfTestReceive.

2.5 LIMITATIONS TO THE PRESENT VERSION

Transferring of data from the WSs to the LCUs is not possible, since this would be in contradiction with a specification stating that the LCUs only should act as slaves, and therefore cannot request any data. Furthermore it is not possible to transfer data between two LCUs using DXF.

The Benchmark test delivered with DXF does not support data transfer from an LCU to a WS.

As a temporary limitation packages are always received as 10000 bytes when it is requested to return packages individual. The last package may contain less than 10000 bytes. This is due to the usage of sockets, but will be fixed from the next release, so that the same package size as sent can be returned on the receiving side.

2.6 DATA FILE TRANSFER BETWEEN DIFFERENT VLT WS ENVIRONMENTS

As a ESO/VLT general requirement, target workstations must be configured to operate independently from the accessibility of disks or directories on other WSs.

It is also forbidden to use, within the control software, file transfer mechanisms, such as ftp or rcp, which require user access permission.

dxf implements a file transfer mechanism, which is compliant with the requirements above.

2.6.1 Configuration

The file transfer mechanism implemented in dxf is based on the classical client/server architecture. The following requirements must be fulfilled:

1. A dedicated client process (dxfFileSend) must be registered in the source environment, i.e. the environment running on the WS where the file to be transferred is located. It is recommended to add this process to the CcsEnvTable (or RtapEnvTable if fullCCS is used). Example:

2. A dedicated server process (dxfFileReceive) is registered in the destination environment, i.e. the environment running on the WS where the file must be transferred. It is recommended to add this process the CcsEnvTable (or RtapEnvTable if fullCCS is used). Example:

To verify that the mechanism works, try (replace xxxx.xxx with an existing file under $INS_ROOT/SYSTEM/DETDATA on the source WS and wyyyy with the actual name of the destination environment):

msgSend "" dxfFileSend TRANSF "-sourceFile xxxx.xxx -destEnv wyyyy

Upon success (Ok returned), the file $INS_ROOT/SYSTEM/DETDATA/zzzz.zzz, copy of xxxx.xxx, should be present in the WS where wyyyy runs.

2.6.2 Application Programmatic Interface

C/C++ applications, which want to use this functionality, have to link to the library dxfTransf and call the function dxfFileTransfer (see 3.5.1).

Tcl applications (e.g. VLT sequencer scripts, instrumentation templates), which want to use this functionality, have to link to the library dxfPublic and call the function dxfFileTransf (see 3.5.2).