Nov 7, 1998 - data transfer from S2 tape to disk or another UNIX device. ..... In example above the Seagate. Barracuda SCSI hard disk speed 5 MB/s is used for internal ..... of the software, as well as verbosity (see Section 9) and external.
S2 Tape-to-Computer Interface (S2-TCI) System User's Manual, Version 0.8
Centre for Research in Earth and Space Technology Space Geodynamic Laboratory Toronto, Ontario, Canada November 7, 1998
1
Contents
1 Introduction 2 System Speci cations
2.1 S2-TCI Features and Capabilities 2.2 S2-TCI Requirements
3 4 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
3 Installation
3.1 Installing the SCD-40 3.2 Installing the S2-CIC 3.2.1 MODE Jumper Con guration (for board rev. PCB1 or later) 3.3 Installing the s2tci Software
4
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 Basic s2tci Con guration
4.1 s2tci Con guration File Name 4.2 s2tci Con guration File Syntax 4.3 s2tci Con guration Basic Parameters 4.4 S2 Environments in con guration le
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : :
5 Diagnostics
ramtest scdtest rcltest cictest passtest
5 5 5 6
6
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
5.1 5.2 5.3 5.4 5.5
4 4
6 6 7 7
8
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
6 Test Data Transfering with File Testing
6.1 Obtaining transfer start time from test tapes 6.2 s2tci Test Execution 6.3 Analyzing le with transfered TVG data
14 : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
7 s2tci Command Line Option Syntax 8 Output Data Files 8.1 Data File Structure 8.2 Data File Directories (Paths) 8.3 Data File Names
9 10 11 12 14 14 14 15
17 17
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
9 Output Verbosity 10 s2tci Theory and Principles
10.1 Th e S2-TCI Data Path 10.1.1 The S2 Playback Terminal (S2-PT) 10.2 The S2 Computer Interface Card (S2-CIC) 10.2.1 The SBus Con gurable Direct Memory Access Card (SCD-40) 10.2.2 The S2-CIC/SCD-40 Connection 10.2.3 The SCD-40 Input FIFO 10.2.4 Host Computer RAM
20 20
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
2
17 18 19
20 21 22 22 23 24 25
10.3 10.4 10.5 10.6
10.2.5 SCSI Device Calculation of Equivalent Playback Mode Calculation of Number of Passes Algorithm: Overview Algorithm Detail: Timing of Individual Bursts
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
A Command Line Options and Con guration File Key Words B Sample Con guration File
3
26 26 27 29 30
33 40
1 Introduction The S2 Tape-to-Computer Interface (S2-TCI) is a system designed to transfer data from an S2 Playback Terminal (S2-PT) (previously recorded on an S2 Record Terminal) to a standard Computer RAM, disk and/or output tape device (e.g. Exabyte, DAT, etc.). The hardware interface between S2 and Computer is via a special-purpose S2 Computer Interface Card (S2-CIC) residing within the S2, and a commercially-purchased DMA controller (DMAC) card residing within the Computer. This interface consists of 16 data lines, 8 MHz transfer clock, and 1 Hz synchronization reference designating startof-burst, all sourced by the S2; bi-directional hardware lines between S2 and Computer provide for direct hardware monitor/control. The software monitor/control interface between S2 and Computer is via the standard S2 Recorder Control Link (RCL) using standard Ethernet network communication (TCP/IP telnet and socket) protocols. The S2-TCI control software provides a simple and automated data transfer from S2 tape to disk or another UNIX device. The user speci es the tape start-time, length of data transfer (e.g. 10 minutes), maximum output le size, and data destination (disk and/or output tape). The S2-TCI control system checks for a valid tape time speci ed by the user, sucient disk space and other miscellaneous transfer issues. It then synchronizes tapes and monitors overall performance. It warns of data transfer diculties and implements a \re-try strategy" to recover data on bad portions of tape. During transfer, various \verbose" levels may be set to instruct the level of monitor information relayed to the user. During the data transfer, the software maintains a data transfer log le summarizing the transfer status. To minimize RAM requirements in the Computer, hence overall system cost, data burst lengths are typically 1 second in duration (requiring 16 MB of Computer RAM for a maximum 16 MB/s transfer rate). Data is transferred in a \striping" fashion consisting of multiple passes through the tape, with tape resynchronization at the start of each pass. The number of tape passes is determined by the speed of the processing throughput. The disk le format consists of a le header, containing data transfer parameters such as S2 tape ID, UTC start time of transfer, the S2 mode of transfer, data rate, etc., followed by the data bits from the S2. The S2-TCI is currently a vital link in the S2 Baseband Processing System [4] and may be adapted for use in a variety of other applications. This manual documents the S2-TCI control software, s2tci,1 the system hardware, S2-CIC SCD-40, and S2-PT, as well as the overall system implementation and use. The manual is divided into the following sections: System Speci cations describes the capabilities and limits of the S2-TCI system in relation to the system requirements. Installation describes the installation process of the S2-TCI system. Operation explains the con guration and execution of the s2tci software. The required user input is de ned and resultant output les explained. Diagnostics discusses the diagnostic tools included with the s2tci software. Theory and Principles of Operation explains the theory behind the software operation and design. This section will most likely be of interest only to other programmers, and need not be read to understand the use of the system. In addition to these main sections there are also useful appendices to explain user input, along with a sample con guration le. The library of s2tci routines, as well as the source code of the mainline program may be found in the directory: /home/s2/tci/source on the ISTS/SGL machine: s2.sgl.ists.ca. 1
4
2 System Speci cations
2.1 S2-TCI Features and Capabilities
The S2-TCI system, under development, boasts the following features and capabilities. The system uses an optimal data transfer playback algorithm to transfer data from S2 tapes to a host computer SCSI device. This alorithm may be adapted to perform data processing in real time, or to re-transfer the data to a larger computer across a network (Ethernet, FDDI). Disk array support: Data from a single transfer may be stored on multiple disks, allowing transfers larger than a single disk capacity. UNIX-like execution of software allows easy integration into automated scripts, allowing it to operate in a variety of applications. A con guration le and numerous command line options give the software the exibility to t a variety of application requirements. Both Sun OS and Solaris OS are supported. S2 control through standard ethernet sockets. Many diagnostic tests are included in software to assist in trouble shooting. A commercially available DMA card is used (SCD-40 from EDT) with a 2Kbyte FIFO for data bu ering. The S2-CIC hardware addition is easily performed on the S2-PT.
2.2 S2-TCI Requirements
S2-TCI system operation requires the following:
S2 Playback Terminal (S2-PT) Sparc 20 Sun workstation: { operating under Solaris 2.4 OS { with at least 24 MB of RAM { fast SCSI hard disk desirable S2-CIC SCD-40 (or 20 nontested) s2tci control software
3 Installation This section describes the installation of the hardware and software required to operate the S2-TCI system.
5
3.1 Installing the SCD-40
For a complete description of the installation process for the SCD-40, please refer to the System Manual for your Sparc Station and the "SCD-20/SCD-40 SBus Con gurable DMA Interface User's Guide" [1].
3.2 Installing the S2-CIC
(NOTE: Before installing the CIC board (for versions PCB1 and later), ensure that the MODE jumper, near U203, is in MASTER position - installed. See the Section 3.2.1 for details.)
The CIC board is designed to be installed in the slot immediately to the right of the UI. In standard S2's, the UI is the right-most card in the system so the slot to the right of the UI is free to house the CIC. If this is not the case for a particular system, the S2's boards should be re-arranged to allow the CIC to be directly to the right of the UI. (Note: If the formatter board is moved in this process, backplane IACK jumpering should also be adjusted accordingly. For example, if the formatter is moved to the left by one slot, then the IACK jumper installed on slot 4 should be removed.) Two cables are needed to connect the CIC to the S2 and DMAC. First is the C2a cable from the UI's C2a connector. This 50-pin twisted-pair ribbon cable plugs into the CIC's input connector, P101 (a 50-pin dual row header). The CIC's output connector, J101 (an 80-pin high-density `SCSI-style' receptacle), is connected to the DMAC's cable. For purposes of testing and debugging, the CIC's Xilinx download chain input connector, P201 (a 10-pin dual row header), is connected via a at ribbon cable to the UI's J3101 header. Installation of this download cable (not required for normal operation) will require the temporary removal of both the UI and CIC from the backplane in order to gain access to the connectors. (Check that the MODE jumper, near U203, is in SLAVE position. See the Section 3.2.1 for details.)
3.2.1 MODE Jumper Con guration (for board rev. PCB1 or later)
A 2-pin jumper, near U203, is used by the CIC to determine the method for con guring the CIC's on-board Xilinx device. Two con guration methods are possible, depending on whether or not the on-board serial PROM, U203, is installed on the board. If U203 is installed, the CIC MODE jumper MUST be set to the MASTER position, ie. jumper installed, which allows the Xilinx to be con gured on power-up from the serial PROM. (That is normal default CIC con guration) If the U203 is not installed on the CIC, the MODE jumper must be set to the SLAVE position, ie. jumper not installed. In this case, the Xilinx needs to be con gured by the S2 through the UI's `box' download port) over the download cable connected to the CIC's Xilinx download chain input connector, P201 (for testing and debugging). Another connector, P202 (a 10-pin dual row header), is provided as a Xilinx download chain output port. The port is con gured so that additional Xilinx devices may be daisy-chained after the CIC's Xilinx in a con guration bit stream. This capability is included for future expansion only.
NOTE: The MODE jumper and P202 are not included on the wire-wrap prototype version of the CIC board. This prototpye must always be con gured through its download port, and daisy-chaining is not supported. 6
3.3 Installing the s2tci Software
After obtaining the correct version of the s2tci control software from ISTS/SGL (for Solaris 2.4 now available), copy the \s2tci.tar.Z" le to the desired directory, change the present working directory to the desired directory and type: gunzip -c tci_tar.gz | tar xvf cd rcl make cd .. make
If any of the above steps fail, please contact the software support group at ISTS/SGL. After completing these steps, the executable \s2tci" will exist in the current working directory. Before s2tci may be executed, it must be con gured with minimum certain basic s2tci parameters. This basic con guration process is explained in Section 4. After con guring the basic s2tci parameters it is recommended to perform diagnostic tests as described in Section 5. Success in diagnostic tests is a way to the next step of transferring the test data from prerecorded SGL test tapes as described in Section 6. The s2tci software is designed as an Unix utility to run it in a form of a command line in the frame of the Unix shell scripts for an automatic data transfering. Options to use in the s2tci command line are described in Section 7.
4 Basic s2tci Con guration The s2tci software may be run in a number of di erent applications through the use of extensive command line options and a con guration le. Before operating s2tci, certain vital basic parameters regarding the speci c system must be entered in the con guration le. After this step is completed, the software may be executed under normal requirements with only three to four command line parameters.
4.1
s2tci
The
Con guration File Name
s2tci con guration le is parsed each time s2tci is executed. The default le name for the s2tci con guration le is \s2tci.cfg". However, the name of the con guration le may be speci ed by the -c le name command line option. This option must be the rst to follow s2tci on the
command line.
4.2
s2tci
Con guration File Syntax
The con guration le consists of two styles of input: ags; and key-value pairs. Flags are key words that require no additional information and simply toggle a function of the s2tci software on or o . (For instance, the file verify key word is an example of a ag.) The absence of a ag key word in the con guration le will disable the function. Key-value pairs consist of a pair of strings separated by an \=" sign. The rst string is treated as the key word and the second string is the value to be assigned to the property of the software associated with the key word. For instance, the s2 IP address = s2recordr.some.site.ca
sequence will set this value in the software. Value format could be: - string as in above example,
7
- integer (without space between digits, 200 or 2500000), - oating point (99.9) - scienti c format (1e-4) Lines can be commented by # sign. The detail explanation for each con guration key word value format can be nd in Appendix A. For a sample con guration le, please see Appendix B.
4.3
s2tci
Con guration Basic Parameters
As already stated, the con guration le contains the following vital system parameters, without which the software cannot operate: s2 IP address = s2name.local host.host.gate
Host S2-PT IP address (can in digit form like 132.251.42.94) should be the same as S2-PT Network Parameter: inet in ethernet con gured as describrd in S2-RT User's Manual p.4.4.1.
cic download = /path/file.bxo
Normally, the Xilinx download le path line should be commented for standard S2-CIC card with on-board serial PROM. (It should be clear at this point after the jumper of the S2-CIC (see Section 3.2.1) has been set.) In case of a custom request for real time data (de/en)coding to get particular data bit patterns in output data ISTS/SGL will prepare Xilinx modeN.bxo les for each N-bit pattern. Those bxo- les can be stored in S2 SRAM or on custom Sun workstation. To select the particular (de/en)coding bit pattern the complete path and bxo le name should be presented in the Xilinx download le path line of the con guration le.
scddev = /dev/scd40
The device driver name of the SCD-40 DMA card is shown in above example for the standard driver installation. In case of SCD-20 DMA card or non standard driver installation device driver name should be changed in accordance with the result device driver name given by installation procedure.
data file path
The full path names of the devices to which data will be written.
processing data rate = 2500000
Data processing rate in 16-bit words per sec; such as the disk throughput speed, measured by exercising with s2tci. For the beginning it is recommended to setup the disk throughput speed as described in disk manufacture speci cation for SCSI bus transfer speed with conversion from Bytes/sec to Word/sec and with rounding to n * 1.25 MW/s. In example above the Seagate Barracuda SCSI hard disk speed 5 MB/s is used for internal Sparc20 Sun workstation disk the speed is about 0.3 MW/s.
Please use the standard s2tci.cfg le included in the s2tci software installation package to enter these parameters by using any available text editor. Other parameters are initialized with default values. They may be changed with entries in the con guration le later on the con guration customizing stage to optimize s2tci performance for some particular application.
4.4 S2 Environments in con guration le
Obviously s2tci software will try to transfer data from S2-PT by playback tapes in standard default S2-PT setup or user setup made by S2 console screen. But for sure it will be better to request s2tci to setup S2-PT with parameters are suitable for data transfer. It is possible by determining
8
the S2 environment name in con guration le line:
environment = env name
At the end of the con guration le the list of di erent environments are placed in the following format: s2_environment = env\_name_1 s2_console_command_1 s2_console_command_2 s2_console_command_3 ... s2_console_command_n s2_environment = env\_name_2 s2_console_command_1 s2_console_command_2 s2_console_command_3 ... s2_console_command_k ... s2_environment = env\_name_m s2_console_command_1 s2_console_command_2 s2_console_command_3 ... s2_console_command_p
So any series of S2 console command can be placed under s2 environment name which will be performed by s2tci software before to start a data transfer. For the basic con guration stage the con guration le line should be: environment = 8x16
and s2 console setup command series under \8x16" name should be: s2_environment = 8x16 userio clkout 8 barrelroll off mode 8x16-1
Please check the s2tci.cfg le and correct it as described above if it is needed. After basic s2tci con guring it is recommended to pass several diagnostic tests described in the Section 5.
5 Diagnostics s2tci has di erent modes of operational testing, which are called diagnostic \tests". These tests range in complexity from simply testing a single component of the S2-TCI system to testing the coordination of the full \striping" algorithm. Diagnostic tests are selected by typing s2tci followed by the associated key word. The diagnostic mode key word must be the rst parameter to follow
9
s2tci, but may be followed by other command line options (discussed in Section 7) to tailor the diagnostic test's operation. See Table 1 for a description of which command line options may be used in which diagnostic test modes. For example, typing: s2tci cictest will place the program into a mode which initiates a single DMA transfer to verify the functionality of the S2-CIC. s2tci diagnostic tests described in the following sections, which are entitled with the associated diagnostic mode key word. Note that typing: s2tci, without any diagnostic mode key word, places the program into the default, S2-TCI transfer mode of operation which determined by line: s2tci mode = standard
in con guration le.
5.1 ramtest s2tci ramtest [-b ram size MW] [-f file path/name] The ramtest mode of operation tests the amount of memory that may be successfully \malloc"ed the s2tci software. So please check if minimum 16 MB memory is available on your workstation issuing the command line: s2tci ramtest -b 8000000
by by
The successful output looks like:
S2-TCI Version 0.8 for Solaris 2.4 Generating sequence of 8000000 TVG-words (16000000 bytes)... completed in 23 seconds. Analyzing buffers... completed in 23 seconds. Cycles analyzed Total Errors Calculated BER
: 8000000 : 0 : 0.00e+00
Test successful.
The next test will evaluate the disk throughput speed: s2tci with the following output:
ramtest -b 8000000 -f file path/test.dat
S2-TCI Version 0.8 for Solaris 2.4 S2-TCI Test of TVG sequence. Generating sequence of 8000000 TVG-words (16000000 bytes)... completed in 23 seconds. 16000000 bytes of data in RAM. TCI_PROC_HEADER_MAKE File Data Rate Header Size
: The date and time of file is: 0097-098-14:24:43 : 8 MW/s : 246 B
File Start Time Recorder Mode
: 97-098-14:24:43 : TVG_test
10
Tape ID
: NO TAPE USED
______________User_info______________________ # LABEL INFO 1 2 3 4
ATTENTION:
: : : :
****** ******
Not for science. This file contains TVG data to be used only for diagnostic purposes.
Writing buffer to file... Buffer successfully written to "/tci11/testing/tst.dat" in 3.6 seconds. Test successful.
To calculate disk throughput speed just divide 8000000 to duration for le writing given in output. In our example disk throughput speed was calculated as 8000000/3.7 = 2222222.22 and rounded to 2500000 in con guration le line processing data rate = 2500000. Correct your con guration le in accordance the actual measured disk throughput speed value. Currently, s2tci ramtest simply generates the S2-TVG2 sequence in a bu er in memory. This bu er is then \re-scanned" bit-by-bit against the identical software-regenerated S2-TVG sequence. At the end of the test, the total bit-errors and bit error rate (BER) are reported. If the -f option is chosen on the command line, the data from the RAM bu er will be written to a S2-TCI le with a test header. The following sequence of events is followed when executing s2tci ramtest diagnostics: 1. s2tci ramtest cr 2. RAM bu er allocated in memory. 3. TVG sequence generated and written to RAM bu er. 4. RAM bu er checked against regenerated TVG if not writing to le. 5. If TVG sequence is written to le with -f option, the RAM bu er is not checked during run-time. File may be checked for bit-errors via mode filetest, i.e. s2tci filetest lename.
5.2 scdtest s2tci scdtest [-r ring buf number] [-rb ring buf size]
To con rm that SCD-40 driver has been installed properly the following command line should be issued: s2tci scdtest
In success the following output will be displayed: S2-TCI Version 0.8 for Solaris 2.4 S2-TCI SCD Driver Loading Test No. of buffer elements: 4 2
The S2-TVG (Test Vector Generator) creates a pseudo-random sequence used in S2-PT diagnostics.
11
Buffer element size : 250000 Bytes Opening SCD driver... Loading SCD driver with 4 buffers of 250000 bytes each. TCI_SCD_RBUF_OPEN : Read issued. Buf#: 0 Addr:780c0 TCI_SCD_RBUF_OPEN : Read issued. Buf#: 1 Addr:b5158 TCI_SCD_RBUF_OPEN : Read issued. Buf#: 2 Addr:f21f0 TCI_SCD_RBUF_OPEN : Read issued. Buf#: 3 Addr:12f288 TCI_SCD_RBUF_OPEN : Waiting for driver to set up. TCI_SCD_RBUF_OPEN : 4 buffers successfully queued. 4 buffers successfully queued in ring. Closing SCD driver and returning ...
Values of allocated memory addresses for ring bu ers will be various and should not be the same as in above example. In scdtest mode, s2tci simply opens the SCD-40 driver, places it into ring bu ering mode, and sends the bu er locations to the driver. No DMA is initiated in this mode. The user may specify the number of bu ers to be used in the ring with the -r command line option and the size of each bu er with -rb command line options. (input as a number of 16-bit words, but displayed output is in bytes) scdtest mode is useful when debugging the interaction with the SCD-40, allowing work to continue even if an S2-PT is not available.
5.3 rcltest s2tci rcltest [+/-i]
To check the proper ethernet connection between following command line:
s2tci
software and S2-PTrun
s2tci
with the
s2tci rcltest -i
The successful output should be: S2-TCI Version 0.8 for Solaris 2.4 S2-TCI Recorder Control Link Test TCI_RCL_OPEN TCI_RCL_OPEN TCI_RCL_OPEN The S2 is in mode
: : : :
Connecting with: "recordr12.sgl" S2-RCL connection open. Successful ping. 8x16-1.
Test successful.
Here is good example to explain how interact options in s2tci command line, parameter setup in con guration le (s2tci.cfg) and internal s2tci software setup. The current internal s2tci software default setup for parameter: init s2 is desable. It means that s2tci software will be not read environment name and not perform all series of s2 console command placed in s2tci con guration le. But the the line s2 init in s2tci con guration le is not commented that means to overwrite internal s2tci default to enable the init s2. The most priority has option in command line and option -i in above example nally set init s2 to desable. To check that environment in con guration le is correct the following command line should be issued:
12
s2tci rcltest -i
and result looks like as: S2-TCI Version 0.8 for Solaris 2.4 S2-TCI Recorder Control Link Test TCI_RCL_OPEN TCI_RCL_OPEN TCI_RCL_OPEN PARSE_S2_ENVIRONMENT PARSE_S2_ENVIRONMENT PARSE_S2_ENVIRONMENT PARSE_S2_ENVIRONMENT PARSE_S2_ENVIRONMENT PARSE_S2_ENVIRONMENT
: : : : : : : : :
Connecting with: "recordr12.sgl" S2-RCL connection open. Successful ping. Searching: s2tci.cfg for descriptor: 8x16 Keyword: 8x16 found. added: "userio clkout 8" added: "barrelroll off" mode: "8x16-1" parsed. added: "clear"
Initializing S2 with environment: 8x16 TCI_RCL_INIT_S2 : Called with 3 console commands. TCI_RCL_INIT_S2 : Entry 0: userio clkout 8 TCI_RCL_INIT_S2 : Entry 1: barrelroll off TCI_RCL_INIT_S2 : Entry 2: clear TCI_RCL_INIT_S2 : The S2 is in mode: 32x4-1 TCI_RCL_INIT_S2 : The S2 is in state: stop TCI_RCL_INIT_S2 : S2 mode set to: 8x16-1 TCI_RCL_INIT_S2 : The S2 is in state: stop TCI_RCL_INIT_S2 : Command: "userio clkout 8" executed. TCI_RCL_INIT_S2 : Command: "barrelroll off" executed. TCI_RCL_INIT_S2 : Command: "clear" executed. Test successful.
5.4 cictest s2tci cictest [-b buf size MW]
The cictest diagnostic test mode is rst test to check the complete s2tci system and performs an all-functions veri cation of the SCD-40/S2-CIC interface. The SCD-40driver is opened and placed into ring-bu er mode with a test bu er of size determined by -b option. As well, an RCL connection with the S2-PT is opened and the S2-PT is placed in "c2test4" mode. Test Vector Generator (TVG) bit pattern is generated by S2-PT in that mode, passed through CIC card to SCD DMA card and placed in workstation test bu er RAM. Then transferred TVG data is compared with TVG data generated internally by s2tci software. The results are displayed and written into log le. It is only one data transfer performed and analyzed for arbitrary S2 1 Hz interuption. The cictest diagnostic test should be performed with following command line: s2tci cictest -b 4000000
13
The displayed output is followed: S2-TCI Version 0.8 for Solaris 2.4 S2-TCI - S2-CIC Verification Test Opening SCD driver. Preparing SCD driver for asynchronous transfer of 8000000 bytes. Opening RCL connection with recordr12.sgl. Initializing S2 with mode c2test4. Dowloading S2-CIC. Testing SCD-40/S2-CIC cable connection. Successful S2-1Hz reception (STAT0). Data transfered. S2-CIC transfer yellow LED "DMA" should be off. Analyzing buffer against TVG sequence... completed in 11 seconds. Cycles analyzed Total Errors Calculated BER
: 4000000 : 0 : 0.00e+00
S2-CIC Test Successful.
It will be give a chance to catch when the yellow LED "DMA" indicator on the CIC card front panel will be turn o during the data transfer. (If the yellow "DMA" LED on the CIC front panel does not turn o and the s2tci software was compiled on SUN OS 4.X then one of the reason of that fault could be that the s2tci software was compiled without "-DPROTO CIC" option. Please check your make le and if it is so, recompile the s2tci with that option.) The detail cictest description is given below. A quick check of S2-CIC functions is performed with the following steps: 1. Check FUNCT1 to STAT1 "hard-wire" In essence, this quick check allows the software to determine if the SCD-40/S2-CICcable is connected and if the Xilinx chip on the S2-CICwas successfully initialized. 2. Check for S2-1Hz on FUNCT0 The driver is instructed to send a software interrupt upon reception and a signal handler is assigned to count reception. 3. Check FUNCT0 triggering of IDV on next S2-1Hz Here FUNCT0 is raised and a RCL time request is made to return on the next S2-1Hz. After the time request returns, s2tci waits until the test bu er is lled. To determine that IDV was raised on the S2-1Hz, this bu er is TVG tested. 4. Check that the resultant BNR disable the IDV The software clears the SCD-40's input FIFO and disables the OVERFLOW bit of the COMMAND register. It then waits to see if this bit is reset. If not, then IDV is low. 5. Veri cation of all 16 data lines The TVG test that veri es S2-1Hz triggering also ensures that all sixteen data lines are operational
14
5.5 passtest
The passtest is designed for debugging the S2-TCI striping algorithm, and may be used for a speci c demonstrating. It should be skipped in standard diagnostic testing procedure. The S2-1Hz software interrupt is enabled and a single pass of data is played back and transferred. This involves full use of the SCD-40/S2-CIC cable signals, the RCL, and S2-TCI internal timers. The user may enter, on the command line, the number of DMA bursts to be transferred during the test with the -nb option (the default is -nb 5). As well, the user may also specify the UTC tape time at which the data transfer will be initiated using the -ttt time string command line sequence. Here, time string is a string of the form speci ed by the time format key word of the con guration le. (The format and parsing of this string is described in Section ??.) The default format for inputing the time is a string of the form: yyyy-ddd-hh:mm:ss like that displayed in the S2 ROS (Recorder Operating System) window. Running s2tci without specifying a start time allows the software to start at the rst integer second after initialization is completed. The initialization and execution occur as described in Appendix 10.5. However, s2tci completes only one pass of the tape data and consequently obtains only a fraction, , of the data (where is given by the duty cycle as explained in Section 10.4). This subset of the data will consist of \sparse" DMA bursts separated in time by the period of the striping cycle, c . Thus, the S2-TCI le, created by an s2tci passtest diagnostic test, will claim to contain 30 seconds of data (for instance) and will even appear this large (in Bytes) to the le system. However, the le will contain a number of large gaps ( lled with zeroes) between each burst. There are no plans to alter this operation; it eliminates the chance that a le created during a passtest could be mistaken for a valid S2-TCI data le. passtest
f
f
t
6 Test Data Transfering with File Testing 6.1 Obtaining transfer start time from test tapes
Standart s2tci kit contains eight prerecorded S-VHS tapes with TVG data recorded in 8x16-2 mode. Please insert tapes into S2-PT, rewind and playback its until they will be aligned. Read "Diag dec time: 008-21:11:47.00" (time code will be di erent from our example) in S2 console window. Read "DATE : January 8, 1997" (date will be di erent from our example) and "Tape position: 0:59:47 +0h01" in User Parms subwindow. Stop the tape playbacking. Now use these values to create: transfer start time and start position as below for our example: 1997-008-21:11:47 0:59:00
At this point it is expected that basic con guring of s2tci.cfg le was performed and all diagnostic tests were made with successful results.
6.2
s2tci
Test Execution
No doubt that instruction for test execution given below is main user guide for an user application transfers. Under normal user requirements, s2tci requires only four command line parameters to
15
operate. These parameters include: -e s2 environment
The S2-PT environments are de ned in the con guration le. Environments de ne the mode in which the data is to be played back by the S2, as well as other system parameters such as the barrell roller, etc.
-ttt transfer time
This is the total amount of data to be transferred from S2 to computer. \transfer time" is given in the number of integer seconds.
-pst tape position
The tape position where tape should be positioned before start data transfer. Be sure that tapes were rewound after inserting to establish right position inside S2. The tape position value is not required to be precisely in accordance the start time. It would be better if the tape position value is determined slightly (30-50 sec) ahead from the exact position for the start time. (why we substract 47 sec in our example). The default format for input the tape position is a string of the form: h:mm:ss like that displayed in the S2 ROS (Recorder Operating System) window. Running s2tci without specifying a tape position allows the software to start data transfer from current tape position.
-tst tape start time
The tape time at which to begin the transfer. tape start time is a string containing the UT time of the start of transfer data. The form of this string may be speci ed in the con guration le. As well, the user may also specify the UTC tape time at which the data transfer will be initiated using the -ttt time string command line sequence. Here, time string is a string of the form speci ed by the time format key word of the con guration le. (The format and parsing of this string is described in Section ??.) The default format for inputing the time is a string of the form: yyyy-ddd-hh:mm:ss like that displayed in the S2 ROS (Recorder Operating System) window. Running s2tci without specifying a start time allows the software to start at the rst integer second after initialization is completed. Only the total tape transfer time MUST be speci ed (with -ttt). If the transfer start tape time or S2-PT environment are not speci ed, the default value speci ed in the con guration le will be used. If a value for these parameters is not speci ed here, s2tci will default to the \c2test4" environment. This diagnostic mode does not require playback of S2 tapes and therefore does not require the \tape start time" parameter. To run test transfer please issue the following command line: s2tci -pst 0:59:47 -tst 1997-008-21:11:47 -ttt 10 -e 8x16
In addition to the parameters described above exists a number of command line parameters for modifying diagnostic and internal operations of the software, as well as verbosity (see Section 9) and external operation. For a complete listing of available parameters, please refer to Appendix A.
6.3 Analyzing le with transfered TVG data
The filetest option is used to compare the contents of an existing S2-TCI le with an internally generated pseudo-random sequence as produced by the S2 Test Vector Generator (S2-TVG). The header information from the le is displayed, and data analysis begins. During execution, a report of
16
the number of errors encountered and the percentage of the job completed is output to screen. Upon completion, the total number of errors and the bit error rate (BER) is reported. If the `-a' (analyze) command line option is invoked, filetest results will be written to screen bit-bybit for each 16 bit word from the S2-TCI le. This option is useful when surprised by the BER results obtained during a normal filetest operation. With the -a option, s2tci filetest output takes the form of two columns: the left column displays the 16-bit word from the internally-generated S2-TVG sequence. The right column displays the 16-bit words from the data le. Only the words which di er from the TVG sequence are displayed, along with up to 30 words that follow the last erroneous line. Following each 30 word display, the user may control the operation of subsequent bit-by-bit analysis with the following options:
s abcd This searches for the next occurrence of the hexadecimal number abcd in the data le. n This searches for the next word that agrees with the TVG sequence (this is useful when there are long sequences of errors in a data le). a This attempts to realign the le with the TVG sequence, which contains missing or misaligned data due to le errors. (very primitive.) q This quits the filetest analysis. cr This causes the filetest analysis to continue without any modi cations to the operation.
When the `-q' (quick scan) command line option is used, s2tci filetest will test only a small portion of the data in the le determined by tt -b size MW option or test buf size = size MW variable in con g le. It advances through the le, testing the rst size MW bytes from the beginning of each integer second of data. In quick scan mode s2tci software calculates so called data dc bias for each bit of 16-bit words and for TVG data option +tvg or tvg data variable in con g le should be used to enable TVG data comparing. This test is useful to quickly determine the contents of a data le. When the command line option filetest is immediately followed by a list of strings, these values will be used as the names of the les to be tested. These values may not begin with a dash (\-") which is used to distinguish the next command line parameter. For instance: s2tci filetest /tci/1995039183420.tci /tci/1995039183430.tci -q
will open the les: /tci/1995039183420.tci and /tci/1995039183430.tci for quick scan testing. If this feature is not used, the lenames may follow the -f command line parameter. Other command line options available for the filetest mode are described in Section 7. Now for the rst time run s2tci in filetest mode as: s2tci letest /your own path in s2tci cfg/TEST-97-008-21:11:47.psr Enjoy the output results and play in accordance with above given description.
17
7
s2tci
Command Line Option Syntax
To operate s2tci in a fully automated manner, it is necessary to include a number of parameters with the execution call. s2tci command line options are treated in a manner very similar to those key words in the con guration le. That is, there are both ag options and key-value option pairs. Every option key word begins with a \+" or \-" character, followed by the option code. Flag options do not require a value to follow the key word (such as the -a command line option used in filetest mode). Key-value options must be followed by one (or more) value(s) to take any e ect. For example, entering the following statement on the command line: s2tci +o -pb -dfn -e c2test4 -ttt 50
will execute s2tci with automatic overwrite power enabled and play back disabled (due to the +o and -pb ags, respectively). As well, the S2-PT will be initialized with the environment de ned by the c2test4 key word found in the con guration le (see Section 4.4) and 50 seconds of data will be transfered (due to the -e c2test4 and -ttt 50 key-value pairs, respectively). Not every command line option applies during every mode of s2tci operation. For instance, the -q option, which applies to the filetest diagnostic test, is meaningless while operating in the standard mode. Table 1 on page 21 charts the di erent command line options used by s2tci and the modes of operation in which they are valid.
8 Output Data Files A single execution of s2tci will result in a number of output les: the data les (containing the \raw" data as output on the C2a of the S2-PT); the real time estimated error log le; and the execution log le. The contents, structure, and rules and conventions for naming these les are described in the following sections.
8.1 Data File Structure
If the total amount of data to be transferred exceeds the maximum le size (as set in the con guration le using the data file szmax key word or on the command line using the -dfs parameter), the data will be stored in a number of les within the data directories (speci ed by data file path and -d). When writing the data transferred from the S2-PT to a storage device, the output from s2tci may be stored in more than one output le. The number of les produced depends upon the user-speci ed maximum size of each le (as determined by the data file szmax member of the con guration le or by the -fs command line parameter). Because all data transfers occur in an integer number of seconds, the maximum le size is speci ed in the number of seconds of data. Each of the output les will contain the following header information that identi es the data and its source: header size The rst four bytes of any S2-TCI le is an integer number which holds the size of the header, in bytes. data rate The next byte holds the data rate in Mega-word per second (where 1 word = 16 bits). UTC time The UTC time corresponding to the rst bit in the data section of the le. This is a string of the form yyyydddhhmmss.
18
S2-PT mode This string contains the mode of the S2-PT playback (for details, refer to [2]). tape ID This string contains a serial number for the tapes used in playback. It is included in the header for diagnostic purposes. user info A number of user info elds are also included in the S2-TCI header. These elds are obtained from the S2-PT before the data transfer is initiated. Following the header of each le is the \raw" data section containing the playback data from the S2-PT. This raw data is a series of 16-bit words, each representing one sample of the output from the S2-PT's 16 User Data Channnels. The LSB of each word represents User Data Channnel 0 and the MSB represents User Data Channnel 15 (see S2-RT User Manual, Table B-5).
For data recorded in modes 4x16-1, 4x16-2, 8x16-1, or 8x16-2, all 16 User Data Channels are active on playback. The rst 16-bit raw data word of the s2tci-generated le represents the sample corresponding to the UTC time placed in the le header. For modes with only 1, 2, 4, or 8 active User Data Channels, each 16-bit raw data word will contain some bits representing these active channels as well as some "empty" bits, lled with 1's. (The active User Data Channels for each playback mode are shown in Table B-5 of S2-RT User Manual.) In these modes, because of the "empty" bits in each raw data word, the size of the le created by s2tci will be much larger than the amount of actual user data played back from tape. To minimize the number of these "empty" bits in each raw data word, the user may choose a di erent S2 playback mode than was used during recording in order to make more of the User Data Channels \active" during playback. For example, data recorded in mode 8x8-1 will have only 8 active User Data Channels on playback, and will use only the rst 8 bits of each 16-bit word in the raw data le. This will result in a le size two times larger than the amount of actual user data on tape. Instead, the user may play back the S2 tapes in mode 4x16-1 in which all 16 User Data Channels are active. This eliminates the empty bits in each raw data word resulting in both a minimal le size and maximum overall transfer eciency. In these cases, mapping between the record and playback User Data Channels is not trivial; a bit mapping table may be provided by SGL under special request from the user. The S2-TCI does not support playback transfer rates higher than 8Mb/s per User Data Channel. Therefore for data recorded in either a 16 or 32Mb/s mode, the user must select a di erent playback mode with a lower data rate as described in Section 10.3.
8.2 Data File Directories (Paths)
The path to which the data les are written is speci ed in the con guration le by the data file path key word. The value given should describe the full path to the available storage device, and the directory in which the les will be placed. If more than one device will be used, simply include multiple data file path lines in the con guration le. s2tci will ll the devices in the order that they are listed in the con guration le. Multiple entries of the same path will be ignored. Additional paths may also be added using the -d command line parameter. The path added using -d will take precedence over all existing paths. For instance, if the following lines exist within the con guration le:
19
data\_file\_path = /tci1/testing/ data\_file\_path = /tci2/pulsar
and the sequence -d /tci3/new is included on the command line, s2tci will ll the devices beginning with /tci3/new/, and ending with /tci2/pulsar/. Note that the previous directory paths are \bumped" forward in the list. As well, if the path speci ed by the -d parameter is already a member of the available paths list, the speci ed path will be brought to the beginning of the list. For instance, if the sequence -d /tci2/pulsar is included on the command line, with the previously mentioned lines in the con guration le, s2tci will ll the devices starting with /tci2/pulsar/, then /tci1/testing/. If multiple paths are included after the -d parameter, each will be added to the beginning of the list such that the last path speci ed in the command line options will be the rst in the list. Note, in the previous example, that the path names may end with a \/" or the \/" may be omitted. s2tci will treat both as equivalent.
8.3 Data File Names
If the total amount of data to be transferred exceeds the maximum le size (as set in the con guration le using the data file szmax key word or on the command line using the -dfs parameter), the data will be stored in a number of les within the data directories (speci ed by data file path and -d). The naming of these les is determined by the data file name entry in the con guration le, or by the -dfn command line parameter. The string supplied by either of these methods will be processed to create the le names for the di erent les in a manner that will be familiar to LATEXusers. All characters in this string will be literally translated into the le name except for the following control sequences: \time{time string} This control sequence will insert a sub-string into the le name containing the UT time of the start of the le (as found in the S2-TCI le header). The formatting of this time string is identical to that explained in Section ??. \ts This control sequence will be replaced by the total number of seconds contained in the data le. ***NOT YET IMPLEMENTED*** \# causes the number of the le (in the sequence of data les) to be included in the le name. ***NOT YET IMPLEMENTED*** For example if the following lines exists in the con guration le: data_file_path = /tci2/pulsar data_file_name = vela_\ts_\time{yy-d-hh:mm:ss} data_file_extension = psr
and the UTC time of the start of the le is 20h00m00s, day 273, 1995, and the le contains 60 seconds of data, then the resultant le name will be: \/tci2/pulsar/vela 60 95-3-20:00:00.psr". Note, that if the data is divided among multiple output les and the above-de ned control sequences are not successful in producing distinct le names, or if they are not used, s2tci will append a number (like that created by the \# control sequence) to the end of each le name before concatenating the designated extension.
20
9 Output Verbosity Di erent situations will require di erent levels of output from s2tci during its execution. Information about state, le writing speed, etc. is available to be displayed on the standard output as well as to be written to the execution log le described in section ??. Each message to be displayed is assigned a priority between 0 and 3 as described in the table below. The verbosity determines which messages will be output and which will be suppressed: All messages with a priority equal to or less than the current verbosity will be displayed. For example, a verbosity of zero will allow only Error Conditions or Vital Information to be output, and a verbosity of three will output everything. Priority 0 1 2 3
10
Description Error Condition or Vital Information Anomolous Condition or State Information Timing and Additional State Information Debugging
Error Condition or Vital Information These messages are displayed at all verbosity levels and usually denote a fatal error that has caused s2tci to terminate. As well, any s2tci operations that may be deemed dangerous (such as overwriting existing les) will be preceded by a message of this priority. Anomolous Condition or State Information Whenever an error occurs for which s2tci has been prepared, a message will be displayed with this priority to inform the user of the action that will be taken. As well, state information such as pass number, tape aligning, etc. is displayed at this level. Timing and Additional State Information At this level, messages include information regarding the time required to write to disk, the time required to align tapes, the burst number, etc. It is useful to set the verbosity of the execution log le to this level. Debugging When debugging, one may wish to see when routines are enterred as well as intermediate values achieved in calculations and manipulations. Many messages are output at this level, and can clutter the screen quite rapidly. This level is useful only when debugging.
s2tci
Theory and Principles
This section discusses the system overview then the algorithm. After describing the details of the S2-TCI from the ch of these elements are coordind into an automated dat ith
10.1 Th e S2-TCI Data Path
The S2-TCI transfers data from an S2 Playback Terminal (S2-PT) to workstation RAM in short \bursts"3 of data using Direct Memory Access (DMA). The data path ows from The term \burst" is used to describe each segment of data instead of the term \frame", as is more common in data communications terminology, to distinguish DMA bursts from frames on the S2-PT's VHS tapes. 3
21
Option b bl c ramtest x x scdtest x cictest x rcltest x letest x x passtest x x standard x x
d f fs i nb np r rb rcl s tt x x x x x x x x x x x x x x x x x x x x x x x x x x x
v A H I PB Q x x x x x x x x x x x x x x x x x
Table 1: s2tci Command Line Options. This table describes which options are appropriate during di erent s2tci diagnostic test modes, as well as in standard operation. Options shown in lower-case require parameter values, e.g. s2tci standard -v 3; options shown in uppercase do not require parameter values, e.g. s2tci standard -pb. Diagnostic test modes are described in Section 5; Command Line Options are described in Section 7. the C2a output of the S2 User Interface Card (UIC), into the S2 Computer Interface Card (S2-CIC) at a maximum data rate of 16 MB/s, the full rate of the S2-PT. At the S2-CIC, the data is piped to the S-Bus Con gurable Direct Memory Access Card (SCD-40)4 across an 80-pin connecting cable. The SCD-40 then strobes the data over the SBus into workstation RAM. Once in the workstation RAM, the data may be immediately processed, written to disk/tape for later processing, or transferred to another computer (eg. super computer) over a high speed data connection (not yet supported in version ). Typically, the speed with which the data are handled after the transfer is much slower than the transfer to RAM (which occurs at a maximum rate of 16 MB/s), inducing a bottleneck in the system data path throughput. To reliably transfer all of the data from the S2 tapes, they must be transferred in short \bursts" using multiple \passes" of the portion of tape data to be transferred. This \striping" algorithm, used by s2tci, is described in detail in Section 10. 0.8
The following sections sequentially describe this data path with a focus on each hardware component and its in uence on the s2tci software.
10.1.1 The S2 Playback Terminal (S2-PT) The S2 Playback Terminal (S2-PT) is the source of the scienti c data, recorded at an observatory, to be played back into the host computer. It is controlled via the Recorder Control Link (RCL)5 software written at ISTS/SGL. The RCL uses standard ethernet sockets to communicate with the S2-PT, and is used extensively by the s2tci software to deliver instructions and retrieve system status information. 4 5
The SCD-40 is a commercially purchased DMA card from Engineering Design Team (EDT) [1]. The S2-PT, its use, and the library of RCL routines are documented in [2].
22
In addition to incorporating the RCL routines, certain characteristics of the S2-PT had a profound e ect on the s2tci control algorithm. For instance, the time required to align the S2-PT tape transports,6 may take up to 40 seconds under normal operating conditions. As well, the S2-PT hardware becomes better synchronized to the tapes, reducing the bit error rate (BER), as playback time progresses. Thus, it is bene cial to begin playback approximately one minute before the start of the actual data transfer, motivating a system design which minimizes the number of times that the tapes must be repositioned and realigned. This has been achieved through the \striping" algorithm, which is described in Section 10 and discussed and justi ed in [3]. Another property of the data output by the S2-PT at the C2a cable is the S2-1Hz signal, which is encoded onto tape, during the observation, synchronous with Universal Time Coordinated (UTC). During playback, the S2-1Hz pulse produced on the C2a cable is output synchronous with the rst bit(s) 7 recorded at an integer UTC second. This UTC second is recorded onto tape and is available via the RCL during playback. Thus, the S2-1Hz signal is used to trigger each DMA burst on the S2-CIC, such that the data entering the workstation RAM is synchronized with a precise UTC time.
10.2 The S2 Computer Interface Card (S2-CIC)
The S2-CIC, designed at ISTS/SGL, receives up to 16 data channels with synchronous clock from the C2a output of the S2-PT via a connecting cable and it transmits to the SCD-40 across an 80-pin connecting cable. Slaved to hardware signals sourced by the SCD-40, the S2-CIC triggers \bursts" of data (transmitted across the connecting cable) synchronous with the S2-1Hz sync signal from the C2a output. These hardware control signals are discussed in Section 10.2.2.
10.2.1 The SBus Con gurable Direct Memory Access Card (SCD-40)
The SCD-40 is a commercially purchased Direct Memory Access (DMA) Card from EDT [1]. Control of the card is accomplished through the standard C library of system calls: it is contacted via the \open()" command; data input and output is accomplished via \read()" and \write()" calls; and low-level control of the SCD-40's registers is performed through \ioctl()" calls to the opened le descriptor. The primary strength of the SCD-40 is the ability to place the card into \ring-bu ering" mode, in which all of the memory to be dedicated to DMA is locked into physical RAM before any transfers are initiated, and remains under the driver's control until it is released Up to eight transports may be used in one recording. The number of bits produced depends upon the number of active data channels and the number of bits per channel 6
7
23
by command. Passing the bu ers to be used in this ring without hanging the process requires asynchronous I/O capabilities. On Sun OS, these capabilities are recognized through the \aioread()" and \aiowrite()" system calls; and on Solaris OS, \threads" are used. In ring-bu ering mode, the SCD-40 driver may be instructed to ll a certain number of bu ers (or divisions) in the ring and wait for con rmation from the application before continuing. In the current version of the s2tci software, the ring bu er passed to the SCD-40 driver is sized to hold exactly one second of data. With the memory resources under the SCD-40 driver's control throughout the entire transfer algorithm, the s2tci software is able to trigger onesecond-long DMA bursts \on the y". These bursts are initiated in hardware synchronous to the S2-1Hz signal, as described in Section 10.2.2. Another property of the SCD-40 that dictates the method of transfer is the fact that it transfers data in 16-bit words with each clock cycle. The current version of the S2-CIC performs no multiplexing of the data that arrives o of the S2-C2a output (ie. it simply acts as a data feed-through). Thus, to utilize the full bandwidth of the S2-CIC/SCD-40 DMA channel, the S2-PTmust be set in a playback mode that uses all 16 lines8 of output on the C2a. For instance, placing the S2-PT into playback mode: 32x4-2 will con gure the output on the C2a into four active data lines (of the available 16) at 32 Mbits/s on each line. Thus, each 16-bit word transfered across the S2-CIC/SCD-40 cable will actually contain only 4 bits of data and 12 bits of garbage. More importantly, the 32 MHz clock exceeds the SCD-40's capabilities, which has a maximum data clock rate of 20 MHz. To fully utilize the DMA bandwidth o ered by the SCD-40, the S2-PT must be set to playback in one of the valid S2 modes as described in Section 10.3.
10.2.2 The S2-CIC/SCD-40 Connection
The S2-CIC and SCD-40 are connected by an 80-pin cable with 16 data lines and synchronous clock. In addition to these lines, the S2-1Hz and bi-directional hardware communication signals are transmitted over this cable. The following is a summary of the hardware signals used to coordinate and synchronize the individual DMA bursts.
DTR: DMA Trigger Request and DMAD: DMA Disable These lines carry hardware signals from the SCD-40 to the S2-CIC and are set high or low by standard s2tci/ioctl() calls to the SCD-40 driver. By setting the DTR (FUNCT0 in the SCD-40 manual) high, s2tci directs the S2-CIC to trigger a DMA burst on the next S2-1Hz tick. The S2-CIC triggers this burst by setting the IDV line high, discussed below. After the burst is initiated (IDV high), the DTR line is lowered again (also through an ioctl() call). In the case of an error, s2tci instructs the S2-CIC to clear the IDV signal by sending a 0-1-0 pulse on DMAD (disable dma FUNCT1 in the SCD-40 manual), simultaneously setting DTR low. DMAD may also be used to implement a simple cable test for the DMAC cable. In this test s2tci can toggle DMAD and con rm that the value read from STAT1 follows these changes. The S2-CIC front panel green "DIAG" LED is driven whenever DMAD is asserted.
the word \line" is used to describe the physical wire data channels of the C2a output and the S2-CIC/SCD-40 cable to distinguish these from the conceptual \channels" that they host. (ie. four lines of data may represent two channels at two bits per channel.) 8
24
IDV: Input Data Valid The Input Data Valid (IDV) signal is sent to the SCD-40 card from the S2-CIC. Data is clocked into the SCD-40's input FIFO when IDV is high. Thus, in raising IDV synchronous with the S2-1Hz, the S2-CIC triggers the SCD-40 to receive a DMA burst starting at an integer UTC second. The S2-CIC's front panel yellow "DMA" LED is driven whenever IDV is asserted. BNR: Bus Not Ready The S2-CIC does not measure the length of time over which the IDV signal to the SCD-40 is to be maintained. As well, it makes no data validity judgements by which it would decide to control IDV. Therefore, once enabled, the IDV signal would remain high inde nitely, were there no means to instruct the S2-CIC to set it low. However, the SCD-40 driver has only a nite amount of space allocated in workstation RAM for DMA, and when this has been lled, its input FIFO will over ow. Just before over owing its input FIFO, the SCD-40 will raise the BNR - Bus Not Ready signal. Therefore, upon receiving the BNR signal from the SCD-40, the S2-CICwill immediately set IDV low, terminating the transfer. This property of hardware interaction bene ts the software in two ways: 1. It is unnecessary for the controlling software to reset IDV low at the end of the burst. 2. In the case of an overload on the SBus or other error, the transfer will terminate without software intervention. Upon realizing that the bu ers are not being lled, the controlling software can check the OVERFLOW bit of the DATA PATH STATUS register in the SCD-40, which is set with BNR. If it nds that this ag is set, it can mark the DMA burst as invalidated, and return to collect this burst in the \missed bursts" pass (described in Section ??).
STAT0: S2-1Hz There are four STAT lines which carry hardware signals from the S2-CIC to the SCD-40. The S2-1Hz signal, from the C2a output of the S2-PT, is directed across the STAT0 line by the S2-CIC. The rising edge of the STAT0 line (S2-1Hz) triggers the SCD-40 driver to raise a software interrupt. This signal is caught by the s2tci control software signal handler, which simply increments the internal sense of \tape time". In doing so, s2tci is \software synchronized" to the S2-1Hz of the S2-PT. This internal tape time is used to verify S2-PT tape time as received via the RCL, and to schedule the bursts of data, as described in Section 10.6. STAT1: Diagnostic Status bit This bit is tied directly to DMAD (FUNCT1) on the S2-CIC and is monitored by s2tci during the DMAC cable test. (see DMAD description)
10.2.3 The SCD-40 Input FIFO
The input FIFO bu ers the data stream from the S2-CIC while it is written to workstation RAM via the SBus. An over ow occurs when the FIFO reaches a certain threshold capacity while the Input Data Valid (IDV) signal from the S2-CIC is still high. This threshold is 2 KB on the SCD-40. Because the S2-CIC does not know the length of each burst, it will maintain IDV until the BNR signal from the SCD-40 is received (as described above). Therefore, when the bu er space in host computer RAM is lled with data at the end of each and every DMA burst, and the data continues to stream from the S2-CIC, an over ow will occur. The 25
SCD-40 will raise the BNR ag, causing the S2-CIC to set IDV low. When the S2-CIC once again raises IDV for the next burst of data, the SCD-40 will begin to clock the contents of its input FIFO into workstation RAM. Unless the FIFO is cleared between bursts, the FIFO will contain the last segment of data received by the SCD-40during the previous burst (before the FIFO over owed). Therefore, after each burst, the input FIFO is cleared by setting low the ENABLE bit in the COMMAND register of the SCD-40 (through an ioctl() call). This operation also has the desirable e ect of clearing the OVERFLOW bit of the DATA PATH STATUS register (also of the SCD-40), which is set high when the FIFO over ows after every burst. After clearing the input FIFO, the next burst of data may be initiated. The rst 16-bit word placed in the host computer RAM will be synchronous with the S2-1Hz signal corresponding to the desired tape time.
10.2.4 Host Computer RAM The input FIFO described in the previous section is a temporary location for the data, for it is immediately strobed into host computer RAM via the SBus. Thus, the data in the S2-TCI system can be seen to go through two stages of cache: 1) temporary storage in the SCD-40 input FIFO; and 2) temporary storage in the DMA memory of the host workstation. Host workstation RAM is dedicated solely to DMA for the entire length of the transfer by placing the SCD-40 into \ring-bu ering" mode. In this mode, all of the DMA memory is locked into physical RAM before any transfers are initiated, and remains under the SCD-40 driver's control until it is released by command. This memory is divided into separate ring bu er "elements", the number of elements depending on the system con guration.9 The s2tci software polls the SCD-40 driver until the rst RAM sub-bu er is lled, at which time it immediately begins processing the burst (writing to disk, transmitting data, etc.). The SCD-40continues to clock data into the remaining elements of the DMA memory, while those lled elements are simultaneously being used by the workstation. Thus, it is evident that with additional bu er elements ( ner division of the same total DMA memory), the processing may begin more immediately after the start of the transfer, and thus use time more eciently. However, more bu er elements requires additional system calls (as in the case of writing each element to disk) to process the data, decreasing overall processing throughput. Other factors contribute to a wise choice of the number of bu er elements, such as the manner in which data is cached when transfering over a network socket. However the DMA memory is divided, successful transfer is guaranteed only when the total size of the DMA memory is large enough to contain one second of S2 data. For example, at 16 MB/s, the total amount of DMA memory allocated must be at least 16 MB. This memory may then be divided into 16 elements of 1 MB each, for example. Thus, processing 9
On the Sun OS platform, the size of each element must be a multiple of 256 KB.
26
may begin on the rst element at: 1s = 0:0625s t = 16
(1)
after the start of the transfer. It is possible to use less RAM than will contain one second of data, and still transfer one second long bursts of data, using an aggressive recycling scheme. However, there is no gain in using such a technique for extended transfers, where processing throughput is the limiting factor.
10.2.5 SCSI Device
A third form of cache in which the data is stored is on a tape or disk device (for long term storage or subsequent processing). The rate at which the data may be written to disk or tape (throughput) is generally much slower than the data rate from the S2-PT. Thus, the ratio of the processing throughput to the S2-PT output data rate de nes the \duty cycle" of the transfer. The duty cycle, as well as other transfer terminology, are de ned in Section 10.4.
10.3 Calculation of Equivalent Playback Mode
As mentioned in Section 10.2.1, the currenct version of the S2-CIC performs no multiplexing and full utilization of the bandwidth o ered by the SCD-40 requires that all 16 lines of the C2a output of the S2-PTbe used. Before discussing the implications of this restriction, it is necessary to quickly review the notation of the standard S2 modes. Each mode is named by the following convention:
CLK xAL-BPC Where: CLK = clock speed on C2a (in MHz) AL = active lines on C2a BPC = bits per channel For example, the S2 mode 8x16-2 signi es that the synchronous clock on the C2a output is set to 8 MHz, there are 16 active data lines, and that there are two bits per channel10 Transferring data using the S2-TCIsystem requires that the tapes are played back in a mode of the form: CLKtx16-BPCt Currently, this implies that CLKt may equal only 4 or 8. BPCt may equal any value supported by the S2. Thus, data that is recorded using less than one half of the S2-PT's bandwidth capacity (ie. less than 4 transports are used) cannot be transfered using the 10
At two bits per channel, the 16 active data lines represent 8 user channels.
27
S2-TCI system in its current state. Data recorded in any mode that uses at least 4 transports may be transfered using the S2-TCI system, but must be played back in either 4x16-BPCt or 8x16-BPCt modes. If the data is not recorded in either of these modes, it must be converted to one of the valid modes using the following calculation: De ne the mode in which the data has been recorded as CLKuxALu -BPCu. De ne the mode in which the data must be played back as CLKt x16-BPCt . Because BPCt is arbitrary from the point of view of the S2-TCI system, the only value that needs be calculated is CLKt , which is given by: u CLKt = CLKu AL 16
(2)
For example, suppose that the data was recorded in mode 32x2-2. Using equation 2, where: CLKu = 32, and ALu = 2 We nd CLKt , by u = 32 2 = 4 (3) CLKt = CLKu AL 16 16 Therefore, the required playback mode is 4x16-1or2.
10.4 Calculation of Number of Passes
As mentioned in Section 10.1, the bottleneck in the S2-TCIsystem is the rate at which the host computer can process or transfer the data from its RAM. This bottleneck necessitates a certain transfer philosophy known as the S2-TCI \striping" algorithm.11 In this method, data are transferred from S2-PT to host computer RAM in short, periodic bursts of data at a high data rate, while it is simultaneously processed at a lower data rate. The ratio of the amount of time spent transferring data via DMA to the amount of time that passes between the beginning of each burst is known as the duty cycle. The following de nitions must be made before an equation for the duty cycle may be developed. (The reader is urged to refer to Figure 1 on page 29 for a graphic representation of these de nitions.)
tb \burst length" { this is the length (in time) of each DMA burst. It is given by the following formula: (4) tb = R B DMA where: B bu er size. The amount of DMA memory available in host computer RAM. RDMA DMA data rate. In the current version, the size of the bu er, B , is chosen such that tb equals one second, when RDMA is given. 11
The philosophy behind the striping algorithm is discussed in greater detail in [3].
28
tc \cycle period" { this is the amount of time spent during each cycle. Because the data
processing occurs simultaneously with the DMA burst (as explained in Section 10.2.4), the cycle period is simply the time required to process each burst, or:
tc = RB
(5)
p
where: B bu er size, as before. Rp data processing rate. Because the striping algorithm is synchronized to the S2-1Hz signal, tc is rounded up to the next integer second when determining the duty cycle. We are now able to de ne the duty cycle in terms of system parameters. Using the de nition stated above: f = ttb = R B RB = RRp (6) c
DMA
p
DMA
Where we have used Equations 4 and 5 to substitute for tb and tc. Thus, the duty cycle is the ratio of data processing rate to data transfer rate. This ratio will approach unity as the processing rate approaches the transfer rate, signifying that the data ow is continuous, i.e is not stopped and re-started.
In the case that the data is being written to disk, the data processing rate becomes the disk throughput, and the claim made in Section 10.2.4 is justi ed by the above proof. Because the data continue to play back from the S2-PT while the host computer is processing, a certain fraction of the data will be ignored during each pass, given by (1 f ), where f is the duty cycle equated above. Let TTT be the \total tape transfer" time or the amount, in time, of the data to be transferred. Now de ne N to be the number of times the tapes must be played back, or the number of passes12 of the data. During each pass, the amount of data transferred will be f TTT . After N passes, N (f TTT ) will be transferred. Therefore, the number of passes that must be made to transfer the entire data set is found when: (7) N (f TTT ) = TTT ! N = 1 = RDMA
f
Rp
Thus, the number of passes is equal to the ratio of the data transfer rate to the data processing rate, or the inverse of the duty cycle, f . s2tci uses Equation 7 to determine the number of passes, based on the data rate on the C2a output of the S2-PT, as determined by the playback mode, and the processing data rate, as speci ed in the con guration le or within the command line parameters (see Section ??). This number of passes, N , is equal to the number of times that the S2-PTtapes must be rewound, repositioned and realigned. Thus, a data processing rate that approaches the data transfer rate will minimize N , and reduce the number of tape realignments required to transfer the entire data set from the S2-PT tapes. 12 The number of passes, N , could also be called the \interleaving factor" or \inverse duty cycle". However, the number of passes is more directly related to the striping algorithm.
29
TTT (Total Tape Transfer Time) DMA Data Transfer Data Processing
Pass 1 T
Pass 2
Pass N Tape Time Clock Time
T = TTT + Tape Realignment Time
Figure 1: The striping algorithm used by s2tci. DMA data transfer occurs in short bursts at a high data rate (RDMA ) for time, tb (shown as the tall dark spikes). Meanwhile, data is processed at a lower data rate (RP ) for the duration of the cycle, tc (wide, lighter boxes). The number of passes, N, is determined by the ratio of the data transfer speed to the data processing speed, as stated by Equation 7.
10.5 Algorithm: Overview
The following is a pseudocode overview of the S2-TCIstriping algorithm.
1. Set all troublesome signals (SIGBUS, SIGSEGV, etc..) to be caught and handled 2. Handle User Input: (a) Open the defaults le and parse its input (b) Parse any user input entered on the command line 3. Allocate the space in memory for the DMA bu er 4. Ensure that there is enough disk space for the transfer 5. Open SCD-40 driver (a) Test cable connection between SCD and S2 CIC 6. Set the DMA driver into ring bu er mode and send it the allocated memory 7. Open RCL connection with the S2 (a) If selected, initialize the S2 and CIC via the S2 RCL 8. IF transferring playback data, and tapes are not playing
30
9. 10. 11.
12. 13. 14. 15.
(a) Instruct the S2 to play Open all output les (default *.tci) Instruct the SCD driver to send the S2-1Hz software interrupt FOR PASS = 1 to number of passes, do steps 11a to 11d (a) IF transferring playback data i. Align tapes to the start time for this pass (b) Set the S2-1Hz count (c) FOR BURST= 1 to number of bursts per pass, do steps 11(c)i to 11(c)xi i. Set burst time (the expected time of DMA burst) ii. Open the appropriate output le for this burst time A. Set the le pointer for this burst time iii. WHILE the S2-1Hz count is burst time A. Mark this burst as missed B. Increment the burst time C. UNTIL burst time exceeds the transfer length iv. IF burst time exceeds the transfer length then break v. Wait until S2-1Hz count is one second before the required burst vi. Trigger DMA burst vii. Read S2 time over RCL viii. Compute the di erence between the burst time and the RCL time ix. IF the di erence in time is not zero, then mark this burst as invalid x. Process the Burst. WHILE bu ers left do: A. Wait for bu er in the ring to ll B. Process the bu er xi. Reset the ring bu er (d) increment the start time for the next pass If any DMA bursts are missed, enter the routine to pick these up Close all output les, the SCD-40 driver, the RCL connection, and free the DMA memory Read header information from the S2 over the RCL and update les RETURN exit status
10.6 Algorithm Detail: Timing of Individual Bursts
Timing a synchronous data transfer on an asynchronous, multi-tasking system like UNIX requires a simple strategy to ensure that the data is transferred at the correct time. The S2-PTtape time is returned, via the RCL, immediately after the S2-1Hz tick that follows the tape time request (i.e. at the next integer second). When ready to initiate a burst, s2tci instructs the SCD-40 driver to raise the DTR (DMA Trigger Request) signal. s2tci immediately follows this command with an RCL tape time request (as shown in Figure 2). Upon 31
S2-1Hz Hardware signal S2-1Hz Software interrupt
S2-PT tape time request (sent via RCL)
RCL returns S2-PT tape time
Time
DTR (FUNCT0) line raised (via ioctl() request to SCD-40)
DTR line lowered
Figure 2: Timing of software requests and signal deliveries during a DMA burst. At some short time after the S2-1Hz hardware signal (black square) is raised, the S2-1Hz software interrupt (grey circle) is delivered to s2tci.
IDV
Time BNR
DTR (FUNCT0)
t=0 t
+BNR
t
-IDV
t
-BNR
IDV
Time BNR
Figure 3: Timing of hardware signals during a DMA burst. The bottom gure gives a detail of the time surrounding the S2-1Hz tick that ends the transfer.
32
the next S2-1Hz tick from the S2-C2a, the IDV line from the S2-CIC will be raised, initiating a DMA burst (as shown in Figure 3). An instant later, the RCL will return the S2-PT tape time, as it was at the start of the burst. This tape time, as returned via the RCL, is compared to the expected time of the burst as maintained by the signal handling function that catches the S2-1Hz signal. s2tci then lowers the DTR line while data is being transferred to host computer RAM and begins processing the data. Upon completion, s2tci checks the internal tape time. At any point during the second that precedes the next burst, s2tci will instruct the SCD-40 to raise DTR, will request the tape time via the RCL, and so the cycle repeats. The hardware signals involved in each DMA burst are depicted on page 31. The times at which the DTR signal is raised and lowered by the SCD-40 are controlled by software (as described above), and are therefore variable. The IDV signal from the S2-CIC, however, is synchronized to the S2-1Hz signal from the C2a output of the S2-PT. The times at which the BNR ag is raised and IDV is lowered can also be precisely calculated: After the end of the transfer (t=0) has passed, the SCD-40 input FIFO over ows and the BNR (Bus Not Ready)
ag is raised (at t=t+BNR ). Due to propagation delay down the S2-CIC/SCD-40connecting cable, IDV is lowered by the S2-CIC at a later time (t=t IDV { where t IDV t+BNR = propagation delay). After IDV is lowered, the SCD-40 lowers the BNR signal (at t=t BNR { also after the propagation delay).
33
A Command Line Options and Con guration File Key Words Unless otherwise speci ed in the following table, each parameter is used in both standard and passtest modes of operation.
34
Option Con g Key Word Default value Description USER SPECIFIED MAIN PARAMETERS: -c
N/A
\s2tci.cfg"
The lename of the S2-TCI con guration le. The default lename is \s2tci.cfg". This must be the rst parameter to follow s2tci on the command line.
-pst
N/A
string
Tape position at which to begin the transfer. The string enterred must contain a representation of the tape position as speci ed by \pos entry format" in the con guration le.
-tst
N/A
string
The UT on tape at which to begin the transfer. The string enterred must contain a representation of the UT time as speci ed by \time format" in the con guration le.
-ttt
N/A
0
The total amount of data to be transferred from S2-PT in the integer number of seconds.
-e
environment
\c2test8"
The environment with which the S2-PT will be initialized. The S2-PT environments are de ned in the con guration le and explained in Section 4.4. The string value enterred must correspond to one of the keywords for the de ned environments.
+/-o
N/A
disable
Enable/disable automatic over-writing of S2-TCI data les. (Default is disabled.)
-d
data le path
NULL
The full path of the storage device to which S2-TCI data les shall be written. In the con guration le, multiple directories may be speci ed by multiple \data le path" lines. On the command line, the '-d' may be followed by multiple string values. Devices will be used in the order in which they are entered in the con guration le. The `-d' command line option will place the named path at the beginning of the list. 35
Option
Con g Key Word
Default value Description USER SPECIFIED MAIN PARAMETERS: (cont'd):
-dfn
data le name
\string"
The string value will determine the le name convention for S2-TCI output data les as described in Section 8.3.
N/A
data le extension
\.tci"
The extension appended to the end of each data le name. (eg. \.tci")
-fs
data lesz max
1 sec
-dr
s2 data rate
0
-pr
processing data rate
2500000
The size of each S2-TCI data le in the number of seconds. E.g. a typical le size may be 60 seconds (resulting in a 480 MB le at 8 MB/s, for example). The data rate for the transfer. Valid input values are 1, 2, 4, and 8 MW/s. (These values indirectly represent the group number of active transports) This parameter will eventually be incorporated into the S2 environment de nitions. The processing data rate MW/s; such as the disk throughput speed. (Default is for Sparc20 Sun workstation with Seagate Barracuda hard disk with wide SCSI interface. USER SPECIFIED PARAMETERS:
SECONDARY
N/A
estBER threshold
1e-4
The maximum estimated bit error rate (estBER) that will be tolerated before a burst of S2 data is marked as invalidated and a retry is scheduled.
N/A
PDV threshold
99.9
The minimum estimate of percent data valid (PDV) that will be tolerated before a burst of S2 data is marked as invalidated and a retry is scheduled.
-v
verbosity display
1
The verbosity level between 0 and 3 of messages printed to the standard output. For a full description of these verbosity levels, please see section 9. 36
Option Con g Key Word Default value Description USER SPECIFIED PARAMETERS: (cont'd):
SECONDARY
-vl
verbosity log le
2
Same as above. For messages printed to the S2-TCI execution log le.
+fv
le verify
1
Speci es that a quick check (dc bias) for the rst 200 words of each second in all S2-TCI data les should be performed after the transfer is completed. (Disable with `-fv' or by commenting out the \ le verify" line in the con guration le.)
-b
test bufsz
200
The size of quick test bu er in 16 bit words. DIAGNOSTIC PARAMETERS:
+tvg
tvg data
1
Speci es that a quick tvg data check for a rst words of each second in all S2-TCI data les should be performed after the transfer is completed. The number of a rst words is determined by test bufsz or -b option. (Disable with `-fv' or by commenting out the \tvg data" line in the con guration le.)
-a
N/A
none
When filetest'ing, this parameter speci es that a bitwise inspection of le data should be displayed on the standard output.
-f
test le name
\string"
When ramtest'ing, the `-f' parameter speci es that the TVG bu er should be written to le (the string value is optional). If the `-f' is followed by a string value, this value will be used for the output lename. Otherwise, the default lename, as speci ed by the \ le name" line of the con guration le will be used. In filetestmode, the `-f' is meaningless unless followed by one or more string values, in which case they specify the names of the les to be opened for testing. 37
Option Con g Key Word Default value Description DIAGNOSTIC PARAMETERS (cont'd): -h
N/A
none
When
filetest'ing, this parameter causes to display only the header contents of the S2-TCI data le on the standard output.
-q
N/A
none
When filetest'ing, this parameter speci es that a quick le scan be performed. This is described in detail in Section 6.3.
-s
N/A
0
In filetestmode, the position in the S2-TCI le at which testing commences (in the case that the le contains multiple seconds of data). The testing starts at the integer second given by the accompanying value, where the physical start position (in Bytes) will depend on the data rate (stored in the header of the le).
-nb
num bursts
5
The number of bursts to transfer during the single pass of passtestoperation. Used only in passtest.
+/-pb
N/A
enable
Enable/disable playback on S2-PT. (Default is playback enabled.)
s2tci
LOW LEVEL PARAMETERS: -s2
s2 IP address
NULL
The Internet Protocol address of the host S2-PT. The value may be either like 556.544.323.444 or recordr12.sgl.
+i
init s2
1
Enable initialization of the S2-PT and S2-CIC over the RCL prior to a S2-TCI data transfer. (Disable with `-i' or by commenting out the \init s2" line in the con guration le.)
N/A
scddev
\/dev/scd0" The device name of the SCD-40 driver (e.g. \/dev/scd0").
38
Option Con g Key Word Default value Description LOW LEVEL PARAMETERS: (cont'd): N/A
cic download
NULL
The lename of the Xilinx (.bxo) le with which the S2-CIC will be initialized before data transfer. The full path name of the le on a storage device mounted on the host S2PT should be given.
-np
num passes
1
The number of passes, N, necessary to complete the data transfer, using the full striping algorithm. This parameter directly depends upon the S2-TCI \transfer duty cycle", as explained in Section 10.4.
-r
rbufs
4
The number of elements (or divisions) used in the internal DMA ring bu er.
-rb
rbufsz
125000
The size of each of the above elements in 16 bit words. This value is calculated according to the data rate of the transfer.
-at
align time
40
The estimated time required for the S2 to align its tapes.
-ap
align patience
50
During playback, the amount of time that s2tci will wait for the next scheduled burst before cueing tapes forward.
N/A
ut entry format
\string"
The format of the string entered for the UT time. User is restricted only to delete the following elements of format: \yyyydddhhmmss" and not to use characters: \y", \d", \h", \m", \s" as delimiters. Default is currently hard-coded to \yyyy-ddd-hh:mm:ss".
39
Option Con g Key Word Default value Description LOW LEVEL PARAMETERS: (cont'd): N/A
pos entry format
\string"
The format of the string entered for the tape position. User is restricted only to delete the following elements of format: \hmmss" and not to use characters: \y", \d", \h", \m", \s" as delimiters. Default is currently hard-coded to \h:mm:ss".
N/A
temp le name
\string"
The format for displaying the time on the stdout and log le Default is currently hardcoded to \yyyy-ddd-hh:mm:ss".
N/A
ut display format
\string"
This parameter gives a temporary le name into which data will be written until the time of the data is known. Default name is \tmunk".
N/A
s2tci mode
\string"
Default mode in which s2tci will begin execution. \standard" is current dafault.
40
B Sample Con guration File ########################################################### # S2 TCI Tape to Computer Interface startup defaults file # ###########################################################
########################################################### # S2-TCI CONFIGURATION FILE ########################################################### ########################################################### # USER SPECIFIED MAIN PARAMETERS: ########################################################### # ENVIRONMENT # The default S2 "environment" to be used when initializing the S2-PT. # The value given must match one of the keywords corresponding to # a defined environment at the end of this file. environment = 8x16 # ===================================================================== # DATA FILE PATH # Default full directory pathname(s) of the disks to which # TCI files are written. If more than one path is to be used, # (multiple disks) then include a separate line for each disk. # (e.g. data_file_path = /tdi/ # data_file_path = /home/s2/imaginary/) # S2tci will fill these directories in the order in which they # occur in this list unless a directory is specified on the # command line with the "-d" option. # TEST data_file_path = /tci22/testing # ===================================================================== # DATA FILE NAME # the format of the output file names. # TEST data_file_name = TEST-\time{yy-ddd-hh:mm:ss} # VELA # data_file_name = vela-\ts-\time{yy-d-hh:mm:ss} # data_file_name = tci\#data # ===================================================================== # DATA FILE EXT # The extension to add to the end of each file name data_file_extension = .psr # ===================================================================== # MAX FILE SIZE # Default maximum number of seconds of data to be written to
41
# a single file. (e.g. 60 for one minute of data to each file) data_file_szmax = 20 # ===================================================================== # S2 PLAYBACK DATA RATE # Override clock speed on the S2-CIC/SCD-40 cable (MW/s) # This value is calculated by the s2tci software depending on the # s2_environment. # easy rule of thumb: s2_data_rate = no. of transports * 1 million # s2_data_rate = 8000000 # ===================================================================== # DISK DATA TRANSFER RATE # the rate at which the transfered data is handled - determines num_passes # given in MW/s processing_data_rate = 2500000 ########################################################### # USER SPECIFIED SECONDARY PARAMETERS: ########################################################### # ===================================================================== # BER # The maximum tolerated estBER before retry # estBER_threshold = 2e-3 estBER_threshold = 2e-4 # ===================================================================== # PDV # The mimimum tolerated PDV before retry PDV_threshold = 99.99 # PDV_threshold = 99.2 # ===================================================================== # VERBOSITY DISPLAY # The default debug level (verbosity) of the S2TCI program (0 - 3). verbosity_display = 1 # ===================================================================== # VERBOSITY LOG FILE # The default debug level (verbosity) of the S2TCI program (0 - 3). verbosity_logfile = 3 # ===================================================================== # VERIFY DC BIAS # Activate dc bias check for first test_bufsz words of each transfered seconds file_verify = 1 # ===================================================================== # TEST-BUFSZ # The size of test buffer in 16 bit words # test_bufsz = 200 # ===================================================================== ########################################################### # DIAGNOSTIC PARAMETERS:
42
########################################################### # ===================================================================== # TVG DATA # activate quick check for tvg data tvg_data = 0 # ===================================================================== # PASSTEST-NUM_BURST # When 'passtest'ing, you may specify the number of bursts to attempt # in the single TCI pass. num_bursts = 5 # ===================================================================== # RAMTEST-TEST FILE NAME # This is the filename to which _test_data_, not observational data, is # written. (eg. test_file_name = tci_tvg.dat) test_file_name = tci_tvg.dat # ===================================================================== ########################################################### # LOW LEVEL PARAMETERS: ########################################################### # ===================================================================== # S2-PT IP-ADDRESS # S2 Playback Terminal (S2-PT) internet address (e.g. recordr12.sgl # or 132.251.41.48 ). s2_IP_address = recordr12.sgl # ===================================================================== # S2-INITIALIZATION # s2tci will automatically initialize the S2-PT and CIC according to the default # environment. To disable this initialization, uncomment this line. # (This is equivalent to adding the -i on the command line) # default is init # init_s2 = disable # ===================================================================== # SCD-40 DEVICE NAME # device address of SCD-24/40 card scddev = /dev/scd0 # ===================================================================== # CIC XILINX BXO FILE # The path name of the .bxo (Xilinx) file downloaded to the S2-CIC. cic_download = /sram/exo/mode.bxo # ===================================================================== # NUM_PASSES # Override number of passes necessary to transfer all of the requested data. # This value is calculated from the ratio of the data destination throughput # to the S2-PT output data rate. # num_passes = 4 # ===================================================================== # RING BUFFER DIVISIONS
43
# The number of divisions used in the DMA ring buffer # rbufs = 16 # ===================================================================== # RING BUFFER DIVISION SIZE # The size of each of the above divisions (valid only when num_passes == 1 # or when dmatesting -- in number of 2-byte words) rbufsz = 125000 # ===================================================================== # ALIGN PRIOR OFFSET # The estimated tape alignment time in seconds. Align requests will # use this value as an offset align_time = 30 # ===================================================================== # ALIGN TIMEOUT FOR FF or RW # The amount of time that s2tci will wait for a position in the tape # without cueing forward by issuing an align command. align_patience = 40 # ===================================================================== # INPUT START TIME FORMAT # format for entering the time on the command line (with -tst) ut_entry_format = yyyy-ddd-hh:mm:ss # ===================================================================== # INPUT START POSITION FORMAT # format for entering the position on the command line (with -pst) pos_entry_format = h:mm:ss # ===================================================================== # OUTPUT TIME FORMAT # format for displaying the time on the stdout and log file ut_display_format = yyyy-ddd-hh:mm:ss # ===================================================================== # TEMP FILE NAME # This parameter gives a temporary file name into which data will be # written until the time of the data is known. temp_file_name = tmunkn # ===================================================================== # DEFAULT S2TCI MODE TO RUN # Default mode in which s2tci will begin execution... s2tci_mode = standard ########################################################### # S2-PT ENVIRONMENT ########################################################### s2_environment = c2test4 barrelroll off mode c2test4 transport 0-0 time validate
44
userio clkout followdata status reset clear s2_environment = c2test8 barrelroll off mode c2test8 transport 0-0 time validate userio clkout followdata status reset clear s2_environment = c2test16 barrelroll off mode c2test16 transport 0-0 time validate userio clkout followdata status reset clear
# this is not generally recommended
# This is a specialmode which pipes diag32 data from the UIC # through the Xilinx on the CIC to come out as mode 4x16-1 s2_environment = vela userio clkout 8 barrelroll on status reset mode 8x16-1 clear # dnld uicdddv /home/s2/.../uwic1.bxo s2_environment = 4x16 userio clkout 4 barrelroll on status reset mode 4x16-1 clear s2_environment = 8x16 userio clkout 8 barrelroll off mode 8x16-1 # this is the fakey mode that Rick made up to test a pulsar processing # kinda thing s2_environment = psr mode 4x4-1
45
transport 0 barrelroll off userio clkout 4 status reset play clear ###################################################################### ###################################################################### # WARNING: DO NOT ADD ANY OTHER PARAMETERS AFTER THE LAST ENVIROMENT # DEFINITION. # # THIS IS THE END OF THE FILE. ###################################################################### ######################################################################
46
References [1] Engineering Design Team, Inc. SCD-20/SCD-40 SBus Con gurable DMA Interface User's Guide, January 1995. [2] ISTS/SGL. S2-PT User's Manual, January 1995. [3] R. Wietfeldt and W. Van Straten. The S2 Tape-to-Computer Interface (S2-TCI) System for Pulsar Applications, Ver. 1.0. Technical report, ISTS/SGL, March 1996. [4] R. Wietfeldt, W. Van Straten, D. Del Rizzo, N. Bartel, W. Cannon, Reynolds Bailes M., and Wilson W. J. The S2 Baseband Processing System for Phase-Coherent Pulsar Observations. PASP Conference Proceedings, IAU Colloquium 160, held in Sydney, Australia, Jan 8-12, 1996, in press.
47
