[teqc] looking for a volunteer or two to test a new option

Lou Estey lou at unavco.org
Wed Dec 6 10:52:40 MST 2017


All,

The next teqc release will have a new set of options '+latency':

[2291] 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.

cheers,
--lou

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 mailing list