# Presentation: 667831

## Archiving at Jefferson Lab	

- (Presentation of work by Chris Larrieu)

## Development Efforts

- Archiving Engine
- History Data Access Interface
- Data Transforms

## JLAB Archiving Engine

- Standard C++: HP-UX aCC, Linux g++
- Plug-in data acquisition modules
- Trigger
- Monitor
- Specialized pre/post event ring buffers
- Easy to add new ones
- Integrated relational database
- Configuration info
- Run log
- Data cross reference, grouping
- CORBA interface
- Efficient

## History Data Access Interface:   Client Overview

- Obtain archive reference
- Initialize range (channel name, begin, end)
- Manipulate (remote?) data
- Pull to client side(?)
- Use data locally.

## Accessing Local History Data

- Client Application

- CADataStore
- Class

- Data Manipulation
- Interface

- CADataStore
- Subclass

- CADataStore
- Subclass

- CADataStore
- Subclass

- Xarr format

- CZAR format

- Frequency
- archiver
-  format

## Adapting CADataStore

- To specialize CADataStore:
- Directory object
- 10 virtual functions
- Archive object
- 2 virtual functions
- Range object
- 4 virtual functions
- range_iterator object
- 1 virtual function

## Why Remote Access?

- Clients don’t require disk access (no disk mounts)
- For low-power data clients
- Put processing close to the data
- Future: cacheing common data requests

## Accessing Remote History Data

- Client Application

- CADataStore
- Class

- Data Manipulation
- Interface

- History
- Data
- Server

## Using CORBA

- Designed to support manipulation of distributed objects: ideal for history API.
- Open source implementation for UNIX / Windows (MICO 2.3.5)
- API uses but does not expose CORBA
- CORBA weaknesses not relevant for history API.

## When?

- Adaptor library by July
- Data manipulation API by September
- History server by December

## Producer / Consumer Model

- Producer pushes *history* *records* into FIFO
- Consumer pulls them out
- Transform consumes and produces

- First In, First Out

- Producer

- Consumer

- records

## History records

- Collection of *fields*
*Name*
*Human-friendly label (e.g. “timestamp”)*
*Standing *
*Computer-friendly label (primary, collating, auxiliary, ...)*
*Value*
*Interprets referenced data (run-time typing)*
*Inlined type-code switching **** no virtual functions*
*Vector / scalar: real, integer, time, opaque*

## Example: volatile CA history record

| “timestamp” | Collating | Scalar time |
| --- | --- | --- |
| “value” | Primary | <run-time dependent> |
| “status” | Auxiliary | Scalar integer |
| “severity” | Auxiliary | Scalar integer |

## FIFO

- Packed field data
- Info record
- Provides static information about contained data (e.g. CA control info)
- Input record
- Conduit for writing sequential data (“write head”)
- push() advances field references
- Output record
- Conduit for retrieving sequential data (“read head”)
- pull() advances field references

## FIFO Schematic

- Input record

- Output record

- Field stat

- Field val

- Field ts

- Field stat

- Field val

- Field ts

- Memory block

- Next memory block

## Run-time Discovery

- Flexibility exacts performance penalty
- Extra level of indirection accessing data
- Dynamic typing implies dynamic memory management
- Mitigating factors
- Avoid rote OO approach of indiscriminate subclassing: better to inline switch statement than incur virtual function overhead.
- Primarily deal with large blocks of homogeneous data.

## Producer

- Create & describe info, data records
- dynamic_record info, data;
- info.add_field (...); data.add_field(...); ...;
- Create fifo, specifying layout
- fifo * output = new fifo (info, data);
- Until done, assign to record then push.
- data[i] = x; data[j] = y;
- output->push();

## Consumer

- Reference input record, fields
- basic_record & irec = fifo.data();
- basic_record::field & x = irec.collating();
- basic_record::field & y = irec.primary();
- Read and use data
- while ( fifo.pull() )
- plot (x,y);

## Transform

- Consumer and producer
- Verify input record supplies compatible data
- Describe output fifo
- Consume input, generating output
- Single pass filters can work in parallel with others