[teqc] looking for a volunteer or two to test a new option
lou at unavco.org
Wed Dec 6 10:52:40 MST 2017
The next teqc release will have a new set of options '+latency':
 teqc +help | grep latency
+latency . output time latency measurements to stdout
+latency .. output time latency measurements to stderr
+latency name output time latency measurements to file 'name'
++latency name append time latency measurements to file 'name'
-latency don't output time latency measurements (default)
The idea is to measure the latency between the time of an epoch, like
a data epoch, and its processing on a computer. If you are streaming data
from a receiver, this latency would include:
- the amount of time for the firmware to package up the record and push it out
(to the Internet, intranet, or whatever),
- the transfer time of the bytes between the receiver's NIC and your computer
(i.e. this portion would roughly be the `ping` time between your computer
and a receiver on the network),
- the time for your computer to read the stream with some software and transfer
it to teqc (e.g. using a 'pipe' in UNIX/Linux), and
- the time for teqc to partially read the record to get its time and then
query the system's time for a comparison.
At the moment, this is only set up to read these BINEX records:
0x00 - metadata and comments
0x05 - position solution information
0x7d - receiver state parameters
0x7e - ancillary site data
0x7f - GNNS observations
In general, though, this option could be added to any format which contains
a time stamp of creation for the individual records or messages of that format.
There are some caveats for the system on which teqc is running:
- the system time needs to be in UTC (otherwise, I have no idea what sort of
time offsets to expect), and
- the system needs to be running NTP against a reliable time server to keep its
system very well synced with UTC.
Testing of this option on Solaris, Linux, and Mac shows that it works pretty well
(e.g. using `nc` to read a stream which is then piped to teqc).
Testing of this option on 64-bit Windows using BINEX files gives roughly the
expected results (many days or hours of latency, of roughly the right value),
but this is not really the intended use case.
Where I need a knowledgeable volunteer or two is to test this option on
64-bit Windows. You'd need some way of capturing a BINEX stream and transferring
this to teqc (and I have no idea how to do this, so don't ask.) Just send an
email to me (not the list) if you are interested in trying it.
Louis H. Estey, Ph.D. office: [+001] 303-381-7456
UNAVCO, 6350 Nautilus Drive FAX: [+001] 303-381-7451
Boulder, CO 80301-5554 e-mail: lou unavco.org
"If the universe is the answer, what is the question?"
-- Leon Lederman
More information about the teqc