The pSB/owamp schema consists of a single DATES table, and a per-day sets of
other tables. The DATES table contains the set of days on which tests have been
done, and the per-day sets of table contain the information about the tests
done that day.

The _NODES tables describe the hosts involved in tests that day, either as
senders or receivers. An example row from the table:

+------------+--------------------------------+----------------------------------------------------------+--------------------------------+----------------+-------+------------+
| node_id    | node_name                      | longname                                                 | host                           | addr           | first | last       |
+------------+--------------------------------+----------------------------------------------------------+--------------------------------+----------------+-------+------------+
| 2082952984 | BLACKBIRD_ITS_STAFF_UIDAHO_EDU | OWAMP Server at University of Idaho in Moscow, Idaho, US | blackbird.its-staff.uidaho.edu | 129.101.66.124 |     0 | 1273190388 | 
+------------+--------------------------------+----------------------------------------------------------+--------------------------------+----------------+-------+------------+

The owmesh.conf entry for that row is:

<NODE=BLACKBIRD_ITS_STAFF_UIDAHO_EDU>
LONGNAME                OWAMP Server at University of Idaho in Moscow, Idaho, US
CONTACTADDR             blackbird.its-staff.uidaho.edu
LAT4ADDR                blackbird.its-staff.uidaho.edu:861
NOAGENT
</NODE>

The node_id field is the internal identifier for the node. The node_name
corresponds to to the NODE= part. The longname to LONGNAME. host will be the
hostname of the node (even if you configure the node with an ip address), and
addr will be the ip address. The first and last columns can be ignored.

The _TESTSPEC tables describes the parameters of the tests done that day. An example row from the table:

+------------+-------------+---------------------+--------------------+---------------+------+--------------+----------------+--------------+
| tspec_id   | description | num_session_packets | num_sample_packets | wait_interval | dscp | loss_timeout | packet_padding | bucket_width |
+------------+-------------+---------------------+--------------------+---------------+------+--------------+----------------+--------------+
| 3815304121 | owamp       |              108000 |                600 |           0.1 |    0 |            0 |              0 |        0.001 | 
+------------+-------------+---------------------+--------------------+---------------+------+--------------+----------------+--------------+

The owmesh.conf entry for that row is:

<TESTSPEC=3954152.IPV4>
DESCRIPTION                     owamp
TOOL                            powstream
OWPINTERVAL                     0.1
OWPLOSSTHRESH                   10
OWPSESSIONCOUNT                 108000
OWPSAMPLECOUNT                  600
OWPPACKETPADDING                0
OWPBUCKETWIDTH                  0.001
</TESTSPEC>

The tspec_id field is the internal identifier for that type of test. You can
ignore the description field as any testspec defined in the owmesh.conf with
the same set of test parameters will map to the same tspec_id, even if the
description differs. The rest of the columns map directly to one of the
parameters defined in the test spec.

The _DATA tables describe the individual test samples. The number of packets
sent will be OWPSAMPLECOUNT. An example row from the table:

+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+----------+----------+--------+--------+------+------+------+-------------+----------+
| send_id    | recv_id   | tspec_id   | si         | ei         | stimestamp           | etimestamp           | start_time                  | end_time                    | min      | max      | minttl | maxttl | sent | lost | dups | maxerr      | finished |
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+----------+----------+--------+--------+------+------+------+-------------+----------+
| 2082952984 | 389679579 | 3815304121 | 3482092896 | 3482092953 | 14955475112573913873 | 14955475358331603536 | Thu May 6 00:01:36 UTC 2010 | Thu May 6 00:02:33 UTC 2010 | 0.046092 | 0.047184 |    240 |    240 |  600 |    0 |    0 | 0.000658989 |        0 | 
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+----------+----------+--------+--------+------+------+------+-------------+----------+

The send_id and recv_id columns will contain ids from the _NODES table. The
tspec_id column contain an id from the _TESTSPEC table. You can likely ignore
si and ei. stimestamp and etimestamp are the start and end timestamps
respectively. They are 64-bit values, the upper 32-bits is the normal unix
timestamp, and the lower 32-bits is the nanoseconds resolution. The start_time
and end_time fields are ISO representations of the unix timestamp. The min
column is the minimum latency seen in the entire session. The max column is the
maximum latency seen in the entire session. The minttl column is the minimum
TTL value seen on the received packets, and maxttl is the maximum TTL value
seen. These can be used to determine if a route flip occurred or not. The sent
column has the total number of packets sent. The lost column has the total
number of columns lost. The dups column has the total number of duplicate
packets seen. The maxerr has the maximum NTP error seen. You can ignore the
finished column for now. 

The _DELAY tables contain a histogram of the packets received in the test
samples. This histogram is divided into buckets of size OWPBUCKETWIDTH seconds.
An example entry from the table:

+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+--------------+-------+---+-----+----------+
| send_id    | recv_id   | tspec_id   | si         | ei         | stimestamp           | etimestamp           | start_time                  | end_time                    | bucket_width | basei | i | n   | finished |
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+--------------+-------+---+-----+----------+
| 2082952984 | 389679579 | 3815304121 | 3482092896 | 3482092953 | 14955475112573913873 | 14955475358331603536 | Thu May 6 00:01:36 UTC 2010 | Thu May 6 00:02:33 UTC 2010 |        0.001 |    47 | 0 | 599 |        0 | 
| 2082952984 | 389679579 | 3815304121 | 3482092896 | 3482092953 | 14955475112573913873 | 14955475358331603536 | Thu May 6 00:01:36 UTC 2010 | Thu May 6 00:02:33 UTC 2010 |        0.001 |    47 | 1 |   1 |        0 | 
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+--------------+-------+---+-----+----------+

The send_id, recv_id, tspec_id, si, ei, stimestamp, etimestamp, start_time,
end_time columns should all match the values in the _DATA table for this
sample. The bucket_width column describes the size of the buckets (in seconds).
Each row in the table corresponds to a single bucket. If the send_id, recv_id,
tspec_id, si, ei, ... all match between two rows, they are two buckets in the
same histogram. The basei and i fields describe the bottom of the bucket. The n
field describes the number of packets in that bucket.

In the above example, the histogram has 2 buckets (since it has 2 rows). The
first row has basei of 47 and i of 0. To calculate the bottom of the bucket,
you add basei + i and multiply by bucket_width. In the first row, you have (47
+ 0) * 0.001 or 0.047 seconds. The second row is (47+1) * 0.001 or 0.048
seconds. So the histogram shows 599 packets arriving with between 47 and 48
milliseconds of delay, and 1 packet arriving with between 48 and 49
milliseconds of delay.

The _TTL table can be used to generate a histogram of TTL values. However, I
don't have a good example of that since I don't have a database with route
changes in it. The idea is essentially the same as the _DELAY table. Here's an
example row:

+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+------+------+----------+
| send_id    | recv_id   | tspec_id   | si         | ei         | stimestamp           | etimestamp           | start_time                  | end_time                    | ittl | nttl | finished |
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+------+------+----------+
| 2082952984 | 389679579 | 3815304121 | 3482092840 | 3482092896 | 14955474871407380144 | 14955475112234090700 | Thu May 6 00:00:40 UTC 2010 | Thu May 6 00:01:36 UTC 2010 |  240 |   88 |        0 | 
+------------+-----------+------------+------------+------------+----------------------+----------------------+-----------------------------+-----------------------------+------+------+----------+

The send_id, recv_id, tspec_id, etc. should all be the same as a row in the
_DATA and _DELAY tables for this sample. The ittl column has the measured TTL
value. The nttl column has the number of packets where this TTL value was
measured. If there were multiple TTL values measured, there'd be multiple rows.
You can then create a histogram out of the values.
