Abstract

We investigate the influence of link bandwidth and link latency on actual data throughput between a LoggerNet server and a CR1000 data logger with NL115 ethernet interface. We find that the achieved data rate is highly dependent on link latency, making it impossible to fully utilize high bandwidths such as these provided by a satellite link.

Setup

A CR1000 is connected to a PC running LoggerNet via an intermediate Linux machine used for transparent traffic shaping.

The LoggerNet PC connects to a port on the Linux machine. This port is being forwarded to the data logger using xinet.d port forwarding.

The traffic is shaped (bandwidth limited and latency introduced) using the “tc” (traffic control) suite of commands.

Results

All speed values were determined using LoggerNet’s “file download” functionality.

An initial test was run without any traffic shaping, the LoggerNet PC and the data logger connected back-to-back via a cross-over Ethernet cable. This achieved around 25,000 bytes per second.

Campbell Scientific confirm this as being (at the lower end of) the expected achievable performance (nominally between 200 and 400 kbits per second).

We then ran a limited number of representative tests as follows:

Note: kbps = kilo bytes per second (a “tc” term)

Table 1 - achieved download rates for various test scenarios

Graphical representation of results in table 1

Discussion

The “upstream”, i.e. from logger to PC, data rate only limits the achieved file download rate for very low latencies. Starting from latencies around 20ms, latency dominates the result in our experiments.

The upstream/downstream bandwidth figures were chosen to match a typical satellite link, such as the ones available from HughesNet. These links typically exhibit a unidirectional delay (=0.5 * ping-time) of around 500ms.

It would seem that the reason for this behavior is the fact that the communications protocol that is used between the logger and the PC (“PakBus”) requires individual requests for every single 1000-byte chunk of data, and does not provide support for a sliding window mechanism similar to the one used in TCP/IP communications.

This results in (at least) one roundtrip delay being added to the total data transfer time for every 1000 bytes transferred.

The resulting low data rates effectively prevent users from downloading larger data sets, independent of the bandwidth they may have available.

Potential Solutions

1. Make the logger send out multiple (100s of) data packets in sequence, without requiring individual requests for each one. Requires change to logger firmware and maybe additions to PakBus protocol.
2. Download data to an intermediate (on-site) PC and forward over the high-latency link afterwards. Requires PC with LoggerNet license on-site. Big power draw. Not suitable for arctic environments.
3. Similar to above, but directly implement PakBus protocol on low-power microcontroller. We have successfully implemented a prototype of this solution, building on the free “PyPak” library, see http://sourceforge.net/projects/pypak/.

Other Issues

Testing so far has revealed that retrieving data over the NL115 interface can result in the logger skipping records. We would expect this to be dependent on what program is running on the logger, and at what frequency it is recording data. Still, yet another rather unpleasant surprise.