NAME

orb2db - create continuous database from orb ring buffer

SYNOPSIS


orb2db [-a wffile] [-c chanmatch]
       [-m srcmatch] [-r srcreject]
       [-p pf-file] [-S state-file] [-s datatype]
       [-t time-tags] [-T tolerance] [-w wfname] [-v]
           orb db [start-time [window]]

DESCRIPTION

orb2db copies data from the orb buffer orb to a continuous database db. A starting time may be specified, otherwise orb2db attempts to coordinate with an existing database, starting after the earliest of the maximum endtimes for each station/channel in the database.

In addition to copying data, orb2db accumulates some statistics about packet errors into the gap, changed, retransmit and duplicate tables.

orb2db expects the sample rate from the packet to be approximately correct, in the sense that the time tags of adjacent packets are within 1/2 sample period of the time calculated from the previous time tag and number of samples and the sample rate. It attempts to handle a clock (or data logger like the Quanterra) where the actual sample rate is slightly different from the rate specified in the packet, by calculating a rate based on the time tags and requiring that the time calculated with this rate and the number of samples match the actual time tag to within 1/2 a sample period. New wfdisc rows are generated when this criterion fails.

orb2db is continuously modifying a set of wfdisc records (usually for the current day) as it runs. As with any Datascope database, no other process should be modifying the output database while orb2db is running. However, in the real time system, it is useful to be able trim this output database by deleting rows representing older data. This trimming improves performance of other programs running against the database.

orb2db implements a simple mechanism for accomplishing this trimming without shutting down and restarting orb2db. A special file is created named after the output database: database.MSGFILE. The first 8 bytes of this file contain a flag which is set while a cleanup is performed, and an integer count of cleanups performed. orb2db tests the flag and the count at every packet; when the flag is set, or the count has changed, orb2db closes its open database, and waits for the flag to be reset. When the flag is reset, it reopens the output database, and finds the new record numbers for the records it is modifying.

The MSGFILE may be monitored or modified using the program orb2db_msg(1). Because there is no acknowledgement (from orb2db that it has paused), it is important to allow sufficient time for orb2db to stop itself, before beginning to modify the database. orb2db_msg sleeps for some period of time before returning, in an attempt to assure this time window. In addition, the time required to clean up the database must be considerably less than the time allowed by the ring buffer size, so that no data is lost.

OPTIONS

PARAMETER FILE

Some kinds of problems can be quietly saved into the database tables changed, retransmit, ratechange and gap. The parameters below allow also printing error messages at regular intervals beyond a particular threshold error rate.

The following parameters affect whether more detailed information about packet anomalies is saved into database tables. The tables make more detailed analysis possible, but when transmissions are poor, or clocks wander a lot, the tables may grow unreasonably large unreasonably quickly. The default is not to write into the tables.

When a packet arrives out of time order, it is presumed to represent a retransmission of the packet. There are several categories of retransmission; recording each type may be individually suppressed.

ENVIRONMENT

see antelopeenv(5)

EXAMPLE

Continuously collect data from the BHZ channel of station RDM from a ring buffer on XYZ to a database rdm.


% orb2db -m '.*RDM.*' -c '.*_RDM_BHZ' XYZ rdm

Collect data for the last 10 minutes from the BHZ channels of stations from a ring buffer on XYZ to a database cels.


% orb2db -c '.*_BHZ' XYZ cels '1996298 15:37' -0:10 0:10

DIAGNOSTICS

Fatal Errors

Generally, orb2db soldiers on in the face of errors; however, it gives up when writes or database updates start to fail.

Non-Fatal Errors

Command Line errors and Initialization errors

SEE ALSO

orbmonrtd(1)
orbstat(1)
orb2db_msg(1)

BUGS AND CAVEATS

Because orb2db keeps many files open, it's often necessary to raise the limit of open files; try unlimit descriptors

If the start and stop times are more granular than the packet size, the actual start and stop times vary from the specification; Data gaps can also cause start and stop times which vary somewhat from the spec.

orb2db requires the rt1.0 schema, for the additional tables gaps, changed, ratechange, and retransmission.

orb2db does not detect any problem when given a source match which doesn't select any sources; it waits forever for a source matching the regular expression, even if there is an explicit ending time.

orb2db should be run so that its database and its waveform files are on local, not nfs-mounted partitions. Having the waveforms on an nfs-mounted partition is particularly troublesome when the partition fills up.

AUTHOR

Daniel Quinlan
Boulder Real Time Technologies, Inc.

Table of Contents
Antelope Release 4.6 Linux 2.4.19-4GB 2004-06-21
Boulder Real Time Technologies, Inc For more information, contact support@brtt.com